feat(ts-estree): add preserveNodeMaps option #494
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have been working on converting some user-land custom TSLint rules to ESLint and this feature has come from that work.
In many cases, I am discovering migrating custom TSLint rules to ESLint is far easier if you first migrate the "infrastructure" over (all the rule and RuleTester config), but keep the rule logic largely the same. (With the idea that you can truly migrate the implementation at some point later).
Naturally, this is only possible if you have access to the two-way AST node maps that may be preserved during conversion.
Preserving the AST node maps is currently only possible if using the
project
option. This is a good start, but as we know theproject
feature is expensive because of its requirement to create full TypeScript Programs.If a custom TSLint rule only requires syntactic information, it is completely unnecessary to create a full Program.
This PR introduces a new option for
typescript-estree
which allows for the user to explicitly control whether or not AST node maps are preserved during conversion.There will be follow up PRs where I add utilities I have created for ESLint rules which meet the above criteria (e.g.
getNodeMaps()
), but I wanted to add the flag itself in a dedicated PR.(NOTE: for backwards compatibility the existing behaviour around
project
causing node maps to be preserved has been maintained here)