-
Notifications
You must be signed in to change notification settings - Fork 64
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
Make use of typescript import resolver #1509
base: main
Are you sure you want to change the base?
Conversation
Hi! Is there anything I can do to help get this feature merged and a new version published? |
All efforts are currently towards flat config. You could apply for joining the work sessions. |
I couldn't find recent info on the sessions you mentioned. How do I apply? |
It should be renamed but here it is: |
I'm sorry for breaking your PR, @mrhyde . I'd ask you to rebase, but I haven't yet acquired an understanding. Sorry for taking long. |
Done :) |
Thank you, @mrhyde. I'm looking into this and after some understanding I find myself wanting to see a reproduction of the problem this solves. Would you mind offering a branch where ESLint can't resolve an import and then another branch where that is solved using eslint-import-resolver-typescript, please? |
There isn't a need to go to such lengths for something so simple. It essentially boils down to the fact that, without this plugin, ESLint cannot resolve TypeScript modules. Try enabling the |
Regarding this particular example; doesn't TypeScript make |
It does, but it doesn't cover all scenarios. For example, when you need to run |
Sorry, I lost you at typescript "doesn't cover all cases". What cases does it not cover, please? You mentioned codemod and find-replace but those are means of modification — they don't describe a case. |
You don't want to use tsc as a linting tool because it's significantly slower, especially on large projects. Nor, adding a build step to your pre-commit hooks would negatively impact the development experience. This PR provides a solution to have the module resolutions checked without actually running the compiler, thereby saving time. |
May I know how long your compilation takes and how long your linting with this resolver takes, please? |
It varies from project to project but approximately building is 2 to 4 times slower |
I feel like I'm looking for absolute numbers. When an import does not resolve we'd get both the linter and the compiler errors, correct? |
In an editor, that is. |
I feel like I need to clarify that it's not about the compiler time per se, but rather about the need to run a compiler just to get those errors. So it's not, for example, a comparison of 10 seconds of compiler time versus 6 seconds of linting time. Instead, it's about 6 seconds versus 16 seconds (compiler + linter) to get the same amount of information that the linter can provide on its own. Yes, you can see both error messages in your IDE (VSCode in my case), but I have already mentioned scenarios where those messages might be missed. |
user=14.81s system=0.11s cpu=118% total=12.559
user=5.55s system=0.59s cpu=172% total=3.559 |
So, in your workflow, you found yourself using some tool to modify code. And you want to run ESLint to make sure that that tool did not mutilate import statements. But you're not concerned about other mutilations enough to run tsc, as well? In that case, is this a modification that acts solely on import statements? Does it merely reorganize your file structure? |
This pull request includes eslint-import-resolver-typescript as a peer dependency and enables TypeScript resolution for
eslint-plugin-import
. And setsimport/no-unresolved
toerror
Doing so we will also avoid having extraneous looking dependency in consumers package.json: