[RTK Alpha]: Is ESNext output for all modules intended?

[rschristian]

At the moment, all output files seem to be targeting esnext, which limits the support to the past couple years at a maximum. Fair enough if this was intended, but thought I'd ask, as there's a few comments in the build script which seem to indicate the idea (for the ESM at least) was to target ES2017:

redux-toolkit/packages/toolkit/scripts/build.ts

Line 54 in ef49075

// ESM, embedded `process`, ES2017 syntax: modern Webpack dev

For example, here's the CJS output with optional chaining, an ES2020 feature: https://www.runpkg.com/?@reduxjs/toolkit@2.0.0-alpha.2/dist/cjs/redux-toolkit.cjs.development.js#1097

Edit: Generally, for maximum compatibility, you'd want to limit the output to ES2017 and only provide that via "exports". There's no guarantees that something consuming "main" or "module" can consume ES2017+.

Edit2: I know optional chaining in particular will trip Webpack 4's parser, so users would need to make sure rtk is transpiled (which is very possible, of course): webpack/webpack#10227

[markerikson]

Yeah, the comments need to be updated there.

And yes, my intent is to ship 100% modern syntax with no transpiling if at all possible, and have it be up to users to transpile if their own build system / target app environment needs it:

https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-alpha.0

That said, yeah, the Webpack 4 situation is the one thing that would make me hesitate slightly. I've been debating whether the main/module artifacts ought to have that output limited.

[rschristian]

Oh wow, nice! Apologies, Ididn't check the release notes there.

I think just about everyone using Webpack is happy to add babel-loader and/or a bit of custom config to tranpsile rtk if needed, so (IMO) that shouldn't hold you back too much.

Happy to close this / have this closed, wanted to avoid adding in another issue / PR if it was an accident as it'd easily get buried.