Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
docs: document import/extensions slowness#6318
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
nx-cloudbot commentedJan 10, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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 onhttps://opencollective.com/typescript-eslint. |
netlifybot commentedJan 10, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
✅ Deploy Preview fortypescript-eslint ready!
To edit notification comments on pull requests, go to yourNetlify site settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Fun! 🧠
Uh oh!
There was an error while loading.Please reload this page.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Oh I tried this withyarn start locally. Weird that the deploy doesn't have it.
@JoshuaKGoldberg - I just made the performance setion its own page entirely. |
JoshuaKGoldberg left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Agreed, this is a good move. Thanks!
I'll send a separate PR standardizing file names toUpper_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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Nit:
| Additionally linters typically run each rule isolated from one another. This has several problems with itlike: | |
| Additionally linters typically run each rule isolated from one another. This has several problems with itsuch as: |
Uh oh!
There was an error while loading.Please reload this page.
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.