feat(typescript-estree): add experimental mode for type-aware linting that uses a language service instead of a builder #6172
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 ## 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: - figure out how to roll-back "dirty" states - memory pressure testing - runtime performance testing
|
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. |
|
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. |
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: