redux-toolkit: (RTK Alpha 2): Cannot resolve types when `moduleResolution` is set to `node16`

A follow up on #2485. When importing anything from @reduxjs/toolkit@2.0.0-alpha.2, typescript cannot resolve types when tsconfig.json’s moduleResolution is set to node16 or nodenext.

I found that adding the extension .js to the declaration imports resolved the issue. For example…

In my file: ./node_modules/@reduxjs/toolkit/dist/index.d.ts export { createSlice, } from './createSlice'; -> export { createSlice, } from './createSlice.js';

Two suggestions for a fix: First, maybe the easiest, is add a post build script to add the extensions to the output. Or second, a search and replace to add the extensions to the all the relevant source files. Want to get some thoughts on a direction before attempting a PR. Maybe there’s a better way.

I tried looking to see if typescript can just add them while compiling… but didn’t find anything that could.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 32 (14 by maintainers)

Most upvoted comments

@eric-crowell : that’s roughly what I’m attempting over in https://github.com/reduxjs/redux-toolkit/pull/3213 .

Yesterday I managed to get a PR initially passing that takes the packed artifact we were already generating (eh… technically I skipped the “generated” part because I needed to iterate faster on the GH Actions job and Playwright step, but that part works already), installs it into a CRA 5 app, builds it, and runs a Playwright test that verifies basic functionality (counter increments, two RTKQ APIs run (with and without React)).

I had done some work a few weeks ago to make local projects for CRA, Next, Vite, and Expo. So now that I can do that for one example, I can start copy-pasting the example projects in and matrix them. That will help verify that any given PR builds and runs correctly.

Once I get that working for 1.9.x on master, we can merge that into the v2.0-integration branch and start using that to check the alpha changes.

Actually, if you or someone else really wants to help… you could start filing PRs targeted at that PR to add equivalent setups for a variety of apps built with different tools.

Off the top of my head, I’d like to target:

  • CRA 4 (w/ Webpack 4)
  • CRA 5 (w/ Webpack 5)
  • Next (also Webpack 5)
  • Vite (ESBuild + Rollup)
  • Expo (which uses Webpack 4 for its “web” target, and I assume Metro for the RN targets)
  • Standard RN
  • Parcel
  • Astro? (which I think uses Vite, but per #3176 someone reported the alpha isn’t loading right )
  • Node, both in CJS and ESM modes
  • Somehow a couple variations on TS’s resolution options
  • Jest and Vitest too?

The other immediately open question would be how to do the equivalent of a Playwright test for an RN app. I’m sure there’s something similar, I just haven’t looked (and I don’t use RN myself).

The app code in the example should be portable across all the examples (store setup, RTKQ API definitions, most of the components). The components would need to be redone for the RN examples (and I have a couple of those bashed together locally I think).

So, porting the example app setups would be a huge help!

export { createDraftSafeSelector } from './createDraftSafeSelector.js'

I realize this is going to sound petty and has no sound basis.

But that looks stupid, and I really don’t want to do that 😦

If I’m reading https://twitter.com/AndaristRake/status/1629168415175835649 correctly, the suggested fix here is actually to drop type: "module" from the RTK package.json.

@eric-crowell : I may have changed my mind one more time 😃

All of the other repos (Redux core, Reselect, React-Redux) would need to clone a repo to get their hands on these example projects in their CI jobs, in order to do the install + build + test steps…

but if they have to clone a repo anyway, it could be this repo instead of a separate repo.

Actually going to spend today’s flying time focusing on some docs feedback I just got ( https://github.com/reduxjs/redux/issues/4495 ), but very much still intending to get more example apps integrated into that branch ASAP.

If anything, I’d rather investigate a new build step to rewrite the generated .d.ts files to have the right import extensions.

I fear we don’t really getting around those .js endings in our sources. They look super weird but the TS team is pretty set that the compiler should not rewrite file names, so this is the direction to go.

I do agree, but sadly, that’s their direction and they’re seemingly sticking to it.

You could always merge type declarations, so there’s a mega .d.ts and no references that could be invalid, but that’s a bit of work on top of normal output behavior.

Seems like https://github.com/microsoft/TypeScript/issues/49160 is a related “everything is broken now” issue.

If I’m reading https://twitter.com/AndaristRake/status/1629168415175835649 correctly, the suggested fix here is actually to drop type: "module" from the RTK package.json.

Sorry, but unfortunately that’s incorrect. You’d need to switch the ESM entries in "exports" to use .mjs, which will have the exact same issue.

This is the direction the TS team have chosen to go (sadly), you’ll need your .d.ts files to use .js in import specifiers if you want to support the node16 module resolution w/ ESM.

Oh boy. Honestly I’ve never even tried to mess with TS’s resolution options. I’ve seen a couple of the discussion threads, but I really don’t know what’s actually needed for any of that.

I’m really not a fan of the ".js" extension in import paths, so I’d really prefer to avoid that if possible.