Added tests to make sure our systems are compatible

The new configuration requires support for much older browsers than the previous one, resulting in a large bundle size.

@skjnldsv Could you confirm, this was intended?

The new configuration requires support for much older browsers

Kind of I guess?
As long as we ensure baseline widely available is supported, that was really the main concerns when establishing that login check (indirectly)

Ok from me 👍

Firefox, Edge and Chrome are the problem there because of old versions, there it should be probably last 5 majors max.

Ideally we have a crafted list per Nextcloud release, because that list above is not what we support officially, its missing iOS 15.
So its currently a regression compared to what we promise to support in that regard.

So for our current promises about supported platforms the query would probably look like:

baseline widely available and last 4 major versions and not dead, firefox esr, ios 15.6

• baseline widely available and last 4 major versions and not dead firefox, chrome, safari with features available for 30+ month but only the last 4 versions
• firefox esr for enterprise
• ios 15.6 as we still support ios 15

But to keep also the support for more used browsers I guess a bit longer query like this makes sense:
https://browsersl.ist/#q=baseline+widely+available+with+downstream+and+last+4+major+versions+and+not+dead%0Abaseline+widely+available+with+downstream+and+%3E0.25%25+and+not+dead%0Afirefox+esr%0Aios+15.8

"ios 15.6" seems like a bad idea, as we'll have to maintain that number

"ios 15.6" seems like a bad idea, as we'll have to maintain that number

ah sorry I was wrong, we updated to 16+ so its probably https://browsersl.ist/#q=baseline+widely+available+with+downstream+and+last+4+major+versions+and+not+dead%0Abaseline+widely+available+with+downstream+and+%3E0.25%25+and+not+dead%0Afirefox+esr

The problem with the current one is in my opinion that it adds some browsers that do NOT support baseline widely available that add a lot of bundle size.

This happens because of the defaults added as an OR instead of an AND.
So everything from default is added additionally and not in conjunction with baseline available.

Another note: baseline query is not supported by browserslist-rs, used by:

• Lightning CSS (built-in in Vite and RSPack)
• SWC (built-in in RSPack)

See:

• build: manually resolve browserslist nextcloud/spreed#16196

We transform browserslist manually to esbuild compatible targets in the vite config, so supported bundlers Webpack and Vite should be good for now.

But this also affects oxc and thus rolldown-vite for the future (yet it still supports the esbuild targets so its working currently): https://github.com/oxc-project/oxc-browserslist

We transform browserslist manually to esbuild compatible targets in the vite config, so supported bundlers Webpack and Vite should be good for now.

Until we minimise CSS.

Until we minimise CSS.

But it also takes esbuild browser targets as per config

But it also takes esbuild browser targets as per config

ES version target doesn't properly reflect CSS optimisations...

That's why we have a complete browserslist config and not just a single ES year.

ES version target doesn't properly reflect CSS optimisations...

I do not talk about ES version but ESBuild targets: https://esbuild.github.io/api/#target
Like chrome58,edge16,firefox57 and similar.
Which is the same as https://vite.dev/config/build-options.html#build-target

We transform browserslist to esbuild to configure it explicitly.

Why do I feel like you two are going far too deep into that topic... 🙈