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

[eric-crowell]

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.

[markerikson]

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.

[eric-crowell]

I feel you. It's been a painful transition going into ESM. I've been searching long and wide for some backwards compatibility. I have some packages that rely on the 'exports' attribute in their package.json, which apparently only works when that Node16 module resolution is set. Otherwise, it's like exports doesn't exist.

As far as this reads, the extensions are required: https://nodejs.org/api/esm.html#mandatory-file-extensions

There's an eslint plugin that has helped me transition to these ESM requirements: eslint-plugin-require-extensions. Allows eslint --fix to add most of those extensions. Scary when seeing a ton of file modifications though.

Ecosystem is in a limbo, haha.

[markerikson]

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.

[incepter]

Hello guys; I hope you are doing well.

I did reproduce this issue in this repo (if you want it as a starting point): https://github.com/incepter/alpha-toolkit-test
(first google result of: redux toolkit typescript codesandbox)

Actually, the solution turns to be quit simple: Just remove "type": "module" from package.json. Is there any need for it? afaik there are no .mjs files in the repo ? There is main and module and types entries, I think (my knowledge is very limited though) that this is enough.

[eric-crowell]

Thank you! Unfortunately, removing the "type": "module" doesn't appear to work for my use case. Maybe the issue is using tsc to output declarations files for a library-type package. Building with vite certainly did not give me any issues though! So that's a step.

@incepter I ran into some similar problems when trying to output some declaration files with tsc in your example:

# ...
src/Toggle.tsx:7:41 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("@reduxjs/toolkit")' call instead.
  To convert this file to an ECMAScript module, add the field `"type": "module"` to './alpha-toolkit-test/package.json'.

7 import { ActionReducerMapBuilder } from "@reduxjs/toolkit";
# ...

[rschristian]

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.

[markerikson]

Well, frankly, now I'm completely lost.

Seriously.

I don't know what I am supposed to do :(

[rschristian]

So this particular issue is quite simple, you just need to ensure the .d.ts files refer to each other with .js. TS will do this for you, so long as you use .js in your import specifiers when referring to local .ts files. Wonky, yes, but it's the way they've gone.

The desired output of ./dist/index.d.ts looks like this:

...
-export { createDraftSafeSelector } from './createDraftSafeSelector';
+export { createDraftSafeSelector } from './createDraftSafeSelector.js';
...

I haven't taken a peek at your build tooling (or attempted to run it), but in theory, it should be as simple as altering this:

redux-toolkit/packages/toolkit/src/index.ts

Line 18 in a636751

export { createDraftSafeSelector } from './createDraftSafeSelector'

to be this:

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

Running tsc itself over that will create the desired .d.ts file as output, as it's one of TS's fundamental rules to not rewrite valid JS (which an import like that is, under some interpretations).

[markerikson]

Seems like microsoft/TypeScript#49160 is a related "everything is broken now" issue.

[markerikson]

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 :(

[markerikson]

https://arethetypeswrong.github.io/ looks useful

[rschristian]

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.

[eric-crowell]

So I started patching @reduxjs/toolkit@2.0.0-alpha.2 myself with various changes; such as removing "type": "module" and adding all this .js extensions to the .d.ts files. It fixes issues directly in @reduxjs/toolkit, but there are still typescript issue if I don't also patch immer, redux, redux-thunk, and reselect.... and probably deeper in the dependencies of those packages too.

I'm about convinced this effort to support node16 module resolution is unreasonably difficult without TypeScript supporting some kind of compatibility without those .js extensions... at least until the majority have shifted over.

I don't know. I am definitely looking forward to updates from that discussion mentioned on Twitter.

[phryneas]

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.