-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TS errors after switching moduleResolution from Node to Node16 #11552
Comments
Same error:
With {
"include": ["**/*.ts"],
"exclude": ["node_modules", "nodeenv"],
"compilerOptions": {
"esModuleInterop": true,
"lib": ["ESNext", "DOM"],
"module": "ESNext",
"moduleResolution": "Node16",
"strict": true,
"target": "ESNext",
"types": ["node", "jest"],
"noErrorTruncation": true,
"skipLibCheck": false
},
"ts-node": {
"files": true
}
} Node See Maxim-Mazurok/vite-ts2834@master...fix for temporary fix using patch-package |
I have noticed this error as well, I am not saying this is a solution, but for me it seems that commenting this line: |
That's an interesting workaround and it seems to work for me. Without using I'd probably still prefer to use patch for vitest instead of mixing vitest with jest types... And hopefully we'll get a proper fix for this soon. |
@santimirandarp @Maxim-Mazurok It's weird, but for me, in my minimal reproduction repo (https://github.com/srflp/vite-node16-moduleresolution-type-errors), adding Still the same errors after running Could you elaborate more how that fixes the issue for you? 🤔 |
What @santimirandarp suggested and what I did was to remove Anyway, I can't seem to get it working anymore either, might've forgotten to disable the patch last time I was trying. |
I replied with a code where I dont get errors locally srflp/vite-node16-moduleresolution-type-errors#1 (comment) ( This is may be a quick workaround but certainly not a solution. ) |
Does Vite just not support Node16 module resolution at this point then? |
Well it works fine with it, but not type-wise, I'm still using the above-mentioned patch Maxim-Mazurok/vite-ts2834@master...fix |
Get TypeScript working with the dagre unit test types. Because Typescript's `nodenext` doesn't work well with vitest's types (see vitejs/vite#11552), we need to instead using jest types, which are luckily pretty much exactly the same as vitest's types. TypeScript actually found a minor bug in the `src/dagre/rank/rank.test.js`, which has been in the upstream code since 2014, see https://github.com/dagrejs/dagre/blob/master/test/rank/rank-test.js#L36-L37.
Get TypeScript working with the dagre unit test types. Because Typescript's `nodenext` doesn't work well with vitest's types (see vitejs/vite#11552), we need to instead using jest types, which are luckily pretty much exactly the same as vitest's types. TypeScript actually found a minor bug in the `src/dagre/rank/rank.test.js`, which has been in the upstream code since 2014, see https://github.com/dagrejs/dagre/blob/master/test/rank/rank-test.js#L36-L37.
More details of the broken types for
|
i think the fix is to set |
👋 Hi Vite maintainers, I work on the TypeScript team and am the author of https://arethetypeswrong.github.io that @karlhorky mentioned above. Would you like help solving this issue? I would be happy to discuss solutions, answer questions, or even raise a PR. However, the core team has previously expressed resistance to fixing these issues, so I want to get clarification on whether the team is interested in making Vite APIs compatible with TypeScript before investing time into this. I really love Vite as a product and would be thrilled to establish a better relationship between our teams and better compatibility between our tools. In the short term though, I just want to type-safely What can I do to help? ![]() |
Hey! We've discussed about this in a team meeting before re |
Fair enough. In that case, we still need to make a resolution with conditions Secondly, there’s the issue mentioned in the OP. The Node ESM types are invalid because they contain module specifiers that would fail to resolve in Node ESM JS files. The JS files themselves, obviously, are totally fine. So the .d.ts and .js files are very out of sync with each other, which is a situation that is impossible to get into with My motivations are twofold: (1) I want the Vite API to be usable for me and for our users, and (2) I want to understand why this is constantly happening. Does Rollup encourage practices that are guaranteed to produce broken types? Would better TS documentation have avoided this issue? Better @rollup/plugin-typescript docs? What made you decide that building your package with tsc isn’t an option? This issue (and this issue tracker in general) may not be the right place for that conversation. I’d be happy to jump on a call or chat in your Discord. It would honestly be a huge help to me to be able to use this as a case study, and maybe I can make it worth your time by fixing this issue along the way 🤞 |
I think I'm fine with that as long as it doesn't break CJS setups. I do like the previous incorrect error have this message though:
Do you mean the errors for
We're also bundling the types with api-extractor (with custom pre/post patch scripts) because we're bundling dependencies (not my decision 😬). But presumably the bigger benefit over tsc in general is that it generates lesser/smaller Also I agree that it's slowly going tangent here, happy to continue in https://chat.vitejs.dev (discord) |
I'm very much interested in the discussion you are having. I think it's great that it's shared here! |
- `compilerOptions.skipLibCheck` is set to `true` to get around Vite issues. See vitejs/vite#11552 for details. - `exclude` is set to `["src/**/*.spec.ts", "src/**/*.spec.tsx"]` to get around @testing-library/user-event issues. See https://github.com/testing-library/react-testing-library/issues/1224 for details.
- `compilerOptions.skipLibCheck` is set to `true` to get around Vite issues. See vitejs/vite#11552 for details. - `exclude` is set to `["src/**/*.spec.ts", "src/**/*.spec.tsx"]` to get around @testing-library/user-event issues. See https://github.com/testing-library/react-testing-library/issues/1224 for details.
Seems like there are good news: in the issue linked above @bluwy said
🥳 just to let folks subscribed to this issue know 😉 |
Describe the bug
After changing moduleResolution from
Node
toNode16
in mytsconfig.json
and runningtsc
in my app, I get plenty of TS errors (pasted below inLogs
).I don't use
vite
in my project, onlyvitest
but the errors seem to come out ofvite
andvite-node
types.One way to bypass this issue is to add
"skipLibCheck": true
totsconfig.json
but it's not a long term solution.Reproduction
https://github.com/srflp/vite-node16-moduleresolution-type-errors
Steps to reproduce
pnpm install
tsc
System Info
Used Package Manager
pnpm
Logs
Validations
The text was updated successfully, but these errors were encountered: