You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 31, 2023. It is now read-only.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR splits out the analyzer codebase between the generic analysis infrastructure in rome_analyze, and the implementation of JS-specific rules in rome_js_analyze
Test Plan
This change is mostly renaming files or moving items between crates with little to no actual code changes, so the code relying on the analyzer should continue building and passing the same tests as before.
Base automatically changed from
feature/analyzer-diagnostic-builder to
mainJune 13, 2022 12:23
How would this infrastructure work when/if we will have rules that touch different languages at the same time? E.g. JSX and HTML
At the root level analysis is always performed on a syntax tree of a known language, using a registry of rules that support analyzing this specific language. In order to write rules that work in multiple languages, they would need to be written once in a way that keeps them "injectable" into instances of the registry specialized for different languages. Currently rules aren't directly tied to a specific language at the type level, this relation only exists indirectly through the Language associated type of the Query AST node, and support cross-language analysis is basically about erasing this relation.
One possibility I see is either making it possible to declare "higher-level unions" across languages, or directly allowing unions to implement AstNode for multiple language types. This would completely sever the rule-language relationship and make it possible to run any rule on any language (the query would simply never match when running CSS-only rules on a JS-only syntax tree for instance)
Another possibility is turning the trait Rule into Rule<L: Language>, allowing rules to be "implemented once" but on a generic language. Here the query type would be more complex to express (as it would need to rely on additional traits and associated types) but this would statically ensure a rule can never be used on a syntax tree using a language it doesn't support
…ome#2700)
* refactor(rome_analyze): move the JS-specific code to rome_js_analyze
* add a constructor function to the analyzer
* add documentation
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
3 participants
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.
Summary
This PR splits out the analyzer codebase between the generic analysis infrastructure in
rome_analyze
, and the implementation of JS-specific rules inrome_js_analyze
Test Plan
This change is mostly renaming files or moving items between crates with little to no actual code changes, so the code relying on the analyzer should continue building and passing the same tests as before.