.browserslistrc support

[brophdawg11]

Remix (with JS enabled) requires a browser that supports ESM via it's usage of <script type="module"> and will fall back to non-JS functionality for those that don't. However, there is still the ability for us to ship broken code to browsers that support ESM by using language features not yet supported by those browsers.

As an example:

• ESM support was added in Chrome 61 + Safari 10.1
• Nullish Coalesing Operator (??) support didn't come until Chrome 80 + Safari 13.1
• So, users on Chrome 61-79 and Safari 10.1-13.0 will load our JS bundles (due to ESM support) but those bundles will fail to parse (due to ?? not being supported)

We've broken apps a few times this far and manually removed the ?? from our @remix-run/react code (#270, #3880, #4561), but it's currently something we have to manually remember not to use. With .browserlistrc support we'd able to code Remix using modern language features knowing that our build will transpile down according to the user's needs.

Related Issues/Discussions:

• All client side javascript fails to run on non ES-2020 compliant browsers (PRODUCTION only) #1901
• Remix causes syntax errors in iOS 11 #4762
• How do I support older browsers? #3240
• esbuild no longer respects target in tsconfig.json #6633

Proposed Approach

• Add https://github.com/marcofugaro/browserslist-to-esbuild into our esbuild config
• Then do we ship any default config?
  • I think the safest approach would be to ship a default .browserlistrc via create-remix that aligns with ESM browser support
    • Pros:
      • Remix apps should avoid these language-syntax errors on all ESM-capable browsers by default
        • Users could change that if they wanted to support a more-modern browser set
    • Cons
      • Remix would likely end up shipping a slightly larger bundle by default
  • We could not ship anything by default (matching current behavior)
    • Pros
      • No impact on default bundle size
    • Cons
      • Remix apps are susceptible to these errors and users have to detect the cause and add a browserlistrc to fix them
      • This might be able to be mostly handled by clear explanations in documentation

Caveats

We should make it clear in our docs that esbuild doesn't polyfill, it only handles transforming unsupported language syntaxes, so folks would still need to be responsible for polyfilling stuff (i.e., Array.prototype.flatMap) if their browsers didn't support it.
We could point them to https://polyfill.io/v3/ presumably.

[sergiodxa]

I think the safest approach would be to ship a default .browserlistrc via create-remix that aligns with ESM browser support

I agree that the default should be any ESM-capable browser, another option is to support last 2 version of every browser, and document this somewhere, so you know that by default Remix browser build is a modern one but you can still support old ESM-capable browsers by using a custom browserlist configuration.

We could not ship anything by default (matching current behavior)

That could be an option if the file is not present but still has a default, so again default to all ESM-capable browsers or last 2 versions or something like that but only if there's no browserlist configuration, and if there's any respect that one.

[brophdawg11]

yeah, the more I think about this the more using a default that aligns with ESM support is the only approach that makes sense. You shouldn't be able to create a remix app from scratch that doesn't work for some specific browser set out of the box (pit of success). And then folks can further optimize if they want to. The bundle size bump is just us fixing the bugs that exist today in Chrome 61-79 (as mentioned above) etc.

[machour]

Remix would likely end up shipping a slightly larger bundle by default

How large are we talking? Would be interesting to see some metrics about what that means for the react build, and an approximation for a route

[brophdawg11]

That should be doable, I don't imagine it would be a cost we couldn't live with, especially since we're now giving you the power to shrink it with a more restrictive .browserlistrc if you're unhappy with the increase

[zolzaya]

Any news? It's big issue for us :(

[machour]

@zolzaya You can see the development process here: https://remix.run/docs/en/v1/pages/contributing#development-process
This proposal still needs to be accepted, before being added to the roadmap and implemented.

In the meantime, you can use patch-package to fix this issue on your side.
See this discord thread for guidance: https://discord.com/channels/770287896669978684/1055014027727749170

[jfsiii]

I think this comment from #4704 highlights a point I wanted to raise.

Even though safari11 supports ES Modules

the compilation fails

✘ [ERROR] Transforming async generator functions to the configured target environment ("safari11" + 1 override) is not supported yet

    node_modules/.pnpm/@web3-storage+multipart-parser@1.0.0/node_modules/@web3-storage/multipart-parser/esm/src/search.js:253:0:
      253 │ async function* arrayIterator(iter) {
          ╵ ~~~~~

This is why I think it's important to distinguish between "users can bring their own esbuild target" and "supports iOS11 <or whatever collection of browsers/platforms>"

Remix can't/shouldn't be expected to have code that compiles to any target (IE6, etc) but specifying some collection like "supports es6-module" or "defaults and supports es6-module, maintained node versions" that are supported would be an important and helpful distinction.

The remix code and it's direct/transitive dependencies would need to be written/chosen to be sure they could compile to that supported set. Users could file bugs if they couldn't compile to a target that was supported (but remixs tests would probably catch anything like that before a release)

[19Qingfeng]

#6114 I think exposing the browser list will help me.

[ShumRain]

This is very helpful for Chinese developers, where users are always reluctant to upgrade their browser