Rework build setup and hopefully fix ESM compat issues

[markerikson]

This PR:

• Updates the redux and redux-thunk deps to the latest alphas, which seem to now have correct ESM handling
• Removes the type: "module" flag from package.json
• Updates the build setup to output .cjs and .mjs files, and all references to those

Based off of, and supersedes , #3211 and #3259 .

[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 da59abc:

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

[markerikson]

OOOOO-kay!

After a very long day today (and a bunch more hours on previous weekends), I have finally come up with a set of packaging changes that appears to be as "correct" as I think we're gonna get, and I've got it being verified via a battery of CI tests that build and run a set of example apps using the PR build artifact. There's also a CI test that uses are-the-types-wrong to verify that the entry points actually seem to work as expected.

I've published new alphas of redux and redux-thunk using a similar set of package configs.

Here's what I ended up with for redux:

  "main": "dist/cjs/redux.cjs",
  "module": "dist/redux.legacy-esm.js",
  "types": "dist/redux.d.ts",
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./dist/redux.d.ts",
      "import": "./dist/redux.mjs",
      "default": "./dist/cjs/redux.cjs"
    }
  },

Note the use of module with a .js extension for Webpack 4 compat. I found that one out the hard way - the cra4 test example failed to find imports when RTK and Redux had a .mjs file in the module key :(

Similarly, for RTK:

  "module": "dist/redux-toolkit.legacy-esm.js",
  "main": "dist/cjs/index.js",
  "types": "dist/index.d.ts",
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/redux-toolkit.modern.mjs",
      "default": "./dist/cjs/index.js"
    },
    "./query": {
      "types": "./dist/query/index.d.ts",
      "import": "./dist/query/rtk-query.modern.mjs",
      "default": "./dist/query/cjs/index.js"
    },
    "./query/react": {
      "types": "./dist/query/react/index.d.ts",
      "import": "./dist/query/react/rtk-query-react.modern.mjs",
      "default": "./dist/query/react/cjs/index.js"
    }
  },

And then I'm still having to use the fallback query/package.json-type files for Webpack 4 as well.

This is all pretty stupid and ridiculous :)

But it seems to work based on all the tests I've thrown at it so far.

[rschristian]

Here's what I ended up with for redux:

  "main": "dist/cjs/redux.cjs",
  "module": "dist/redux.legacy-esm.js",
  "types": "dist/redux.d.ts",
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./dist/redux.d.ts",
      "import": "./dist/redux.mjs",
      "default": "./dist/cjs/redux.cjs"
    }
  },

"main" being .cjs can still get you in trouble (same issue as "module", and a bit more likely as .cjs was spec'd after .mjs). Any reason why you're not going with .js? It's a CJS package, after all, this is one of the benefits.

[markerikson]

Dunno. Guess I figured that if I was going to use one format-specific file extension, I might as well use it in both places?

[rschristian]

For "exports", it's just more explicit, so entirely up to you, but there's no guarantees that a tool that reads "main" understands .cjs. This is one of the big benefits of not going with "type": "module", being able to keep the legacy (non-"exports") fields untouched.

Fair enough if you don't want to support them, they'd be a few years behind at this point.

[markerikson]

To be honest, I'm not sure what tools would read "main" at this point. Older Node, I guess? Webpack 4, Vite, and TS should be looking at exports. I think I maybe saw that Parcel 2 just merged exports support recently? which seems odd.

Would be nice to have at least one CI example where that's getting exercised. If you've got suggestions on what tools actually care about "main" at this point, let me know.

[rschristian]

To be honest, I'm not sure what tools would read "main" at this point. Older Node, I guess?

Older Node and bundlers/configs that have chosen not to use or prioritize "module", etc.

It's not going to be a common issue, but it is one that could be avoided in exchange for some explicitness over the module format.

Webpack 4, Vite, and TS should be looking at exports

Webpack 4 does not use "exports" to my knowledge. I believe that was gated behind v5. There's probably loaders that support it though.

I think I maybe saw that Parcel 2 just merged exports support recently? which seems odd.

It did, yep, as it's even more of a headache for bundlers to implement (if you can believe it).

Would be nice to have at least one CI example where that's getting exercised.

Easiest demonstration is Node v12.6 and prior.

Totally up to you, but it's pretty cheap (IMO) to support a wider range of users.

[markerikson]

My typo, that should have been Webpack 5 :)