Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
feat(typescript-estree): add experimental mode for type-aware linting that uses a language service instead of a builder#6172
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
… that uses a language service instead of a builder program## PR Checklist- [x] Steps in [CONTRIBUTING.md](https://github.com/typescript-eslint/typescript-eslint/blob/main/CONTRIBUTING.md) were taken## OverviewThis is just an experiment to help address memory issues (#1192), maybe performance, and maybe out-of-sync types (#5845).I was looking into some code around the place and noticed that TS exposes the concept of a "document registry" - which is a shared cache that can be reused across certain TS data structures to deduplicate memory usage (and I assume improve performance by deduplicating work).This PR implements a new parser strategy which uses TS's "Language Service" tooling, which in turn leverages the document registry. "persistent parse" tests pass - which at least proves that it works in some manner of speaking.One interesting thing to note here is under the hood the language serivce doesn't use a builder program. I believe the idea is that the document registry is supposed to forego the performance implications of that? I don't know exactly - it will require more testing. Though it's worth mentioning that this means this could replace our current "single-run" codepaths because it doesn't use a builder program.TODO:- figure out how to roll-back "dirty" states- memory pressure testing- runtime performance testing
nx-cloudbot commentedDec 6, 2022 • 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 commentedDec 6, 2022 • 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. |
something weird is happening on the CI - dunno why it's OOMing. |
Cc@jakebailey I know you had an inclination about helping us improve the perf of the tooling. I was hoping you could help me by providing some TS insider insight ☺ Do you think this approach will help out a lot compared to the existing builder program approach? Would it be worth us building our own layer on top of the document registry instead of reusing the language service? |
Honestly, I have no clue;@sheetalkamat or someone may have better insight. |
Closing this old draft for housekeeping since there are merge conflicts and it's taking up space in the open PRs list. Nothing bad will happen in my housekeeping if this is re-opened. Don't mind me. 😄 |
@bradzacher do you still want to work on this now that |
Let's put a pin in this - if we find that the project service works for all cases then there's no need for us to worry about improving the manual config case, I think. |
Uh oh!
There was an error while loading.Please reload this page.
Overview
This is just an experiment to help address memory issues (#1192), maybe performance, and maybe out-of-sync types (#5845).
I was looking into some code around the place and noticed that TS exposes the concept of a "document registry" - which is a shared cache that can be reused across certain TS data structures to deduplicate memory usage (and I assume improve performance by deduplicating work).
This PR implements a new parser strategy which uses TS's "Language Service" tooling, which in turn leverages the document registry. "persistent parse" tests pass - which at least proves that it works in some manner of speaking.
One interesting thing to note here is under the hood the language serivce doesn't use a builder program. I believe the idea is that the document registry is supposed to forego the performance implications of that? I don't know exactly - it will require more testing. Though it's worth mentioning that this means this could replace our current "single-run" codepaths because it doesn't use a builder program.
TODO: