docs: document import/extensions slowness #6318
Conversation
|
Thanks for the PR, @bradzacher! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
docs/linting/Troubleshooting.md
Outdated
| 1. to enforce file extensions are always used, | ||
| 2. to enforce file extensions are never used. | ||
|
|
||
| ##### Enforcing extensions are used |
There was a problem hiding this comment.
Note that the font size for #####s is pretty small:
Maybe a good time to bump that up a bit?
There was a problem hiding this comment.
How did you see this? Did you check it out locally?
When I tried the netlify deploy link above it doesn't include my changes :(
There was a problem hiding this comment.
Oh I tried this with yarn start locally. Weird that the deploy doesn't have it.
|
@JoshuaKGoldberg - I just made the performance setion its own page entirely. |
There was a problem hiding this comment.
Agreed, this is a good move. Thanks!
I'll send a separate PR standardizing file names to Upper_Snake_Case.mdx.
Edit: #6325
| That generally makes them run orders of magnitude slower. | ||
| Linters are designed to run in a parse, check, report, fix cycle. This means that there is a lot of intermediate work that needs to be done before a linter can fix a formatting issue with your code. | ||
|
|
||
| Additionally linters typically run each rule isolated from one another. This has several problems with it like: |
There was a problem hiding this comment.
Nit:
| Additionally linters typically run each rule isolated from one another. This has several problems with it like: | |
| Additionally linters typically run each rule isolated from one another. This has several problems with it such as: |
This was a surprising result that I found at work today.
I found that
import/extensionstook ~30s for a total codebase run - which was 1/3 of the overall lint time!!!I replaced it with the listed
no-restricted-syntaxconfig which in comparison runs in less than 1ms over the entire codebase, which is a YUGE win.This hadn't been documented before because when I wrote this performance section I didn't realise that this lint rule could be slow.
I tried to clearly spell out the fact that the alternative has false positives and is not a 1:1 replacement. Now-a-days I've found that there's very few npm packages that still include
.jsin their name, and false-positives likefoo.js.tsshould really not happen - so in practice it'll be 1:1, but still tried to make it clear there could be false positives.