v6: Cannot find module '@typescript-eslint/*' or its corresponding type declarations #7284
Comments
|
Sweet baby jesus, thank you so much! 🙏 Docs says it's "very likely" that you want to have these configurations for modern node projects: And this solves the issue aswell. |
|
I spent a lot of time troubleshooting this so I am sharing this information if it can be useful for anyone else. I am using eslint-plugin-local-rules to create custom rules without having to create packages which means that if I want to use To work around this, I simply created a second {
"extends": "../tsconfig.json",
"compilerOptions": {
"baseUrl": "./",
"module": "esnext",
"moduleResolution": "Bundler"
},
"include": ["**/*.ts"],
"exclude": [],
"ts-node": {
"compilerOptions": {
"module": "NodeNext"
}
}
}And lastly in my parserOptions:
project:
- 'tsconfig.json'
- 'eslint-local-rules/tsconfig.json' |
|
Creating a custom rules package using But I can't see in the official documentation mentioned anywhere a need to change anything in |
|
I have some unit tests for custom rules that I used to run with I'd gladly use So even if you change the How should the PS I know you're not responsible for TS + jest + Node interplay, but I failed to find any information on what to do now. Maybe the answer is not that tricky and you happen to know it. It's probably not only me having this issue, it was hard to find it on the web. |
Yeah, this seems like an issue on their end. I'd suggest filing an issue on We don't use |
|
Side note that I believe that specific code path is only used if you use a |
|
@JoshuaKGoldberg, thanks for the suggestion -- I went for the swc approach and it worked out of the box! |
|
setting |
|
@AdamQuadmon without any details on your codebase or errors you're seeing, I don't know what you mean by "the issue". Let's go with one of two actionable followups:
|
This updates to a more modern moduleResolution, from the default of node/node10. Relevant typescript-eslint issue: typescript-eslint/typescript-eslint#7284
This updates to a more modern moduleResolution, from the default of node/node10. Relevant typescript-eslint issue: typescript-eslint/typescript-eslint#7284
|
Changing the module resolution in tsconfig worked for me in terms of satisfying TypeScript error, however ESLint itself is still yelling at me "Unable to resolve path to module '@typescript-eslint/utils'." ( |
|
@GYuriy suggest just turning off that rule for TS files, tbh. It's duplicating checks that TS already does for you and it's logic requires separate configuration to even attempt to mirror the module resolution that TS uses. Also it does a lot of disk reads which makes it a pretty slow rule. |
Although there is a later version of `@typescript-eslint/typescript-estree` available, using any later version will require updating to a newer module resolution than "umd": typescript-eslint/typescript-eslint#7284
|
I'm just wondering: why don't we add back the For instance, I started to look at The |
|
We don't do it because it's an inaccurate representation of our package. It allows users to misconfigure their project and then access private implementation details that don't form part of our API.
Major version upgrades are the time for breaking changes and not all breaking changes are going to be easy for all codebases to update for. We do our best to minimise the impact but some changes are just hard. As an example - in v9 eslint will remove some methods they have recently deprecated. For projects like us that support v7+ this will be really hard for us as we'll need to create utils to help support both legacy and current versions. That's on us and how we use eslint though - not on the eslint team to keep things around to make our lives easier. |
Although there is a later version of `@typescript-eslint/typescript-estree` available, using any later version will require updating to a newer module resolution than "umd": typescript-eslint/typescript-eslint#7284
This is required to use `@typescript-eslint/utils` v6+. See: typescript-eslint/typescript-eslint#7284
This is required to use `@typescript-eslint/utils` v6+. See: typescript-eslint/typescript-eslint#7284
This is required to use `@typescript-eslint/utils` v6+. See: typescript-eslint/typescript-eslint#7284
Because `@typescript-eslint` uses package.json `exports`, we had to upgrade some dependencies which didn't support `exports` (see typescript-eslint/typescript-eslint#7284). Affected dependencies: - `jest`
* Fix bug caused by @typescript-eslint update. see typescript-eslint/typescript-eslint#7284 (comment) * CI: bumps version to v0.0.21 * Try to do the bumping manually instead * Replace gh-action-bump-version with basic script * Use git-auto-commit-action to commit and push changes --------- Co-authored-by: Automated Version Bump <gh-action-bump-version@users.noreply.github.com>
I have the same problem using jest + swc. My jest.config.ts is But when I try to run tests, I still get errors like @akwodkiewicz @JoshuaKGoldberg I wonder if you have any pointers on how you got your swc+jest setup to work? |
|
@JoshuaKGoldberg, @JavaScriptBach replying to my own comment from half a year ago Funnily enough, I totally forgot about this Jest + ts-node issue, and stumbled upon it again last month. So I reported a bug (jestjs/jest#14740) (without mentioning this issue) and proposed a fix: jestjs/jest#14739 (a quick mitigation of the bug is to use @JavaScriptBach, trying to help you with swc, this is my module.exports = {
testMatch: ['**/*.spec.ts'],
transform: {
'^.+\\.(t|j)s$': '@swc/jest',
},
coverageDirectory: '<rootDir>/../../../test-reports/eslint-plugin-unit-tests',
};I did not have to pull off any additional tricks |
|
Figured out my issue. I had to change the absolute path of import { TSESLint } from "@typescript-eslint/utils";
const ruleTester = new TSESLint.RuleTester({
<
F438
span class="pl-c1">parser: resolve(
__dirname + "../../../../../node_modules/@typescript-eslint/parser",
),
});to const ruleTester = new TSESLint.RuleTester({
parser: resolve(
__dirname + "../../../../../node_modules/@typescript-eslint/parser/dist",
),
}); |
|
Just very painfully encountered this last week, per #8244. Figured I'd repeat my feedback from there: I have never seen a library that drops support for node <16 also start requiring moduleResolution: node16 - for every other package I've ever seen, dropping support for node <16 means that the new version may fail at runtime, not at typecheck time. So @typescript-eslint/ is definitely an outlier here - I've been using moduleResolution: node with 100s of other packages with no problems at all. ... so I have to ask - would it be possible to achieve your goals of hiding internal implementation details while also enabling moduleResolution: node to continue working? I suspect that as long as you don't have .d.ts present for your various private files, imports to them wouldn't resolve so with some effort you could avoid exposing your implementation details in the node10 resolution. that said... also understandable if you just don't want to spend the effort. But clearly the reason this is such a common point of confusion is that @typescript-eslint is probably one of the few packages requiring node16/bundler resolution already. |
|
@dgoldstein0 you cannot hide internals from node10 unless you physically bundle your declarations. People often accidentally import from these internal files because TS suggests auto-imports from those files. The only way to hide these files from node10 is to remove them entirely - and the easiest way to do that is bundling. But that's an extra step that we as volunteer maintainers need to maintain purely to support building plugins against old versions of TS - which is a rarer usecase. This is also a problem because it means that someone could accidentally write a runtime import that would typecheck fine, but would crash at runtime. This is bad! With node16 we can declare our API surface in our package.json and have both node enforce it at runtime and typescript enforce it at typecheck time without any effort on our end.
The issue isn't our side - it's the typescript side! People don't realise that setting This is why in the next version of TypeScript they're improving the error messages around this to help teach people that they're using the wrong module resolution. |
|
At this point it has been over 6 months since v6 has been released. So I'm going to close this. |
Uh oh!
There was an error while loading. Please reload this page.
Overview
A handful of folks have mentioned that after upgrading to v6, trying to
importfrom@typescript-eslint/*packages such as@typescript-eslint/utilscauses a new TypeScript type error:This is not a bug. We intentionally dropped support in v6 for Node <16 as those versions of node are EOL. v6 uses package.json exports - which requires Node 16+ and isn't supported by that older module resolution strategy.
To fix the issue, switch your TSConfig's module resolution to a newer version, most likely
"bundler","node16", or"nodenext". See the aka.ms/tsconfig"moduleResolution"docs for more information.{ "compilerOptions": { "moduleResolution": "bundler" } }See TypeScript's new modules reference docs for more information.
Issues that are duplicates of this one:
https://arethetypeswrong.github.io/?p=%40typescript-eslint%2Futils%406.0.0 also shows a nice table of which
moduleResolutionvalues we support. It's all of them exceptnode10.Keeping this issue open so it shows up more in searches.
The text was updated successfully, but these errors were encountered: