Migrate the RTK package to be full ESM

[markerikson]

This PR attempts to convert the RTK package from its existing "contains ESM and CJS modules, but not fully ESM", to be fully ESM with {type: "module"} and still support CJS:

• BREAKING: Sets the main RTK package.json file to be {type: "module"}
• BREAKING: Updates all entry point package.json files to use exports to point to the types, ESM file, and CJS file
  • I still have main and module in there because WHO KNOWS WHETHER THOSE STILL END UP GETTING USED BY SOME TOOLS OR NOT 🤷‍♂️
• Updates the build script:
  • Fixed ESM compat on execution by replacing use of __dirname and fixing the Terser import
  • Switched all build targets to be "esnext", to ensure the output is untouched other than TS transpilation
  • Moved all CJS build artifacts to be nested a level deeper in each entry point in a ./cjs/ folder, ie, ./dist/query/cjs/
  • Added {type: "commonjs"} package files to those folders
  • Turned off the UMD build artifacts for now

I've done some hand-testing of a locally-built version of this. I set up an example project that used all three entry points ( @reduxjs/toolkit, /query, and /query/react), then that ported it to several different build tools and ran both dev and prod builds for each:

• Vite 4: worked
• CRA 4 and 5: worked
• Next 13: needs redux-thunk to be converted over to ESM as well, as the middleware array ended up as [ {default: thunk()}, api1.middleware, api2.middleware]. Installing a local build of redux-thunk with similar ESM changes made that work
• Parcel: worked
• RN Expo: it found the correct file ( rtk-query-modern.js ), but choked on the optional chaining syntax inside, and I don't feel like messing with RN further. Important thing is it found the right file.

I also tested this with a tiny Node script that imported all three entry points in both a CJS and an ESM file, and got that running without errors.

Finally, I tested this with the https://publint.dev/ CLI run against all three entry point package.json files, and it gave me a ✅ for each.

Given that, I'm tentatively hopeful that the exports configuration is actually sufficient.

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 6f9591e:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration
rsk-github-issues-example	Configuration
@examples-query-react/advanced	Configuration
@examples-action-listener/counter	Configuration

[markerikson]

Well. The good news is I think the runtime code works.

Bad news is Jest is being a pain. In particular, something about the way it's importing redux-thunk makes the default import an object like {default}, which is not a middleware function, and thus the tests explode when we try to create a store.

I spent the last couple hours hacking around with the thunk exports and republishing it locally. Switching the thunk package over to not having a default export at all sorta helped, but now something about the "no dev middleware in prod" test is failing.

So, close, but can't even build this branch yet.

edit

wrote up a slightly more detailed status update, so pasting here.

where I left off yesterday was that:

• redux-thunk has a default export, and Jest was now choking on that
• I published [email protected] that tried to convert it to ESM, but still had a default export included. That helped build with Next, but not our local Jest tests
• I then did a local-only publish of redux-thunk that dropped the default export and only had named exports. That actually seemed to help, but one of our RTK tests that asserts NODE_ENV=production behavior for getDefaultMiddleware was breaking

Some folks in Reactiflux suggested that it might be worth investigating a switch to Vitest. I'd prefer not to do that if possible, on the grounds that migrating to a different test runner is not my priority or something I want to spend time on. On the other hand, it could also be something that would be beneficial in general and for this specific problem.

It looks like we have about 200 references to "jest" in the repo. Most of them are either timers, jest.fn(), or jest.spyOn().

If someone wanted to take a stab at doing a Jest->Vitest migration PR to target this branch, I'd be interested in looking at it.

[markerikson]

Hmm. So on the one hand, #3102 looks pretty good in that the migration is working and all RTK tests are passing.

On the other hand... surprisingly I'm not seeing the Immer default import issues here in CI that I was seeing locally.

I'm confused :)

[markerikson]

Okay, let's do this!

Technically the OpenAPI test failed, but that's a timeout issue