Support for node.js Dual CommonJS/ES module packages

[ZosoDerGoldene]

Background: In an attempt to reduce boilerplate or duplication, I want to use the actions defined as part of createSlice() both on the client side and on the server side. That fails as node.js ignores the "module" key, and rather requires "export" to be defined (for details see here).

So any import is always treated as CommonJS, and working around this by using the default export breaks the client side...

[markerikson]

From what I've been told, adding an exports key would be considered a breaking change, and thus has to wait for a new major version.

Changing package formats is on our list of things to look at for a 2.0 release:

• Future planning: RTK 2.0? #958

Actually, I'm a bit confused. Are you saying that RTK itself needs support for dual modules in its own package.json, or are you referring to something else? Can you show exactly what you're trying to do?

[ZosoDerGoldene]

1. While I fail to understand which use cases export would break, that can definitely be attributed to my superficial knowledge of the node.js module resolution process, and that's not taking into account earlier versions or other tooling that might break.
2. I'm sure that my use case is not urgent enough to warrant even trying to find out if whether it is a breaking change or not.
3. That said, RTK already supports dual modules (by having a main (for CommonJS) and module (for ESM) entry in its package.json. Packagers like WebPack understand that and pick what is appropriate for the case. Node.js doesn't, as outlined in the document linked above:

This enabled Node.js to run the CommonJS entry point while build tools such as bundlers used the ES module entry point, since Node.js ignored (and still ignores) the top-level "module" field.

As I'm building a system that involves logux, actions are processed both on the client and server, so I would want to reuse the action definitions created by createSlice() on both ends, but being unable to treat RTK as an ESM in node.js prevents me from doing so. So currently, I don't use createSlice(), but rather use typescript-fsa to define actions centrally and piece the client-side together manually using createReducer() and createEntityAdapter() (which do most of the heavy lifting, anyway).

[markerikson]

Note for later reference - Sindre Sorhus has a big gist with instructions on switching to pure ESM:

https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

[a-bronx]

Looks like I faced a similar problem. In my case, I use RTK in a Typescript project targeted for a browser/ESM, but at the same time I run unit tests in nodejs using a ts-node, with a ts-node/esm loader. If I use named imports like import { ... } from "@redux/toolkit", then I can build the project for a browser, but cannot run my unit tests in ts-node because a CommonJS flavor is selected and it does not support named imports. If I use a import RTK from "@reduxjs/toolkit" to workaround the named import issue, then tests work fine, but now it fails on a build.

[markerikson]

#1960 ended up as the bigger issue, so I'm going to close this as a duplicate. Full ESM support was added in https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0-alpha.1 - please try it out and give us feedback!