-
-
Notifications
You must be signed in to change notification settings - Fork 763
refactor(linter/plugins): add environments definitions #17292
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(linter/plugins): add environments definitions #17292
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
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.
Pull request overview
This PR adds a code generator that creates TypeScript environment definitions for Oxlint JS plugins. The generator reads JavaScript global variable definitions from the javascript-globals crate and outputs them in a structured format with readonly and writable arrays. These definitions are not yet used but will be integrated in a subsequent PR (#17293).
- Adds
OxlintEnvsGeneratorin Rust to generate environment definitions from thejavascript-globalscrate - Generates
apps/oxlint/src-js/generated/envs.tscontaining environment presets with readonly/writable variable lists - Updates build infrastructure to include the new generator
Reviewed changes
Copilot reviewed 4 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tasks/ast_tools/src/generators/oxlint_envs.rs | New generator that reads JavaScript globals from the javascript-globals crate and outputs TypeScript environment definitions with variables categorized as readonly or writable |
| tasks/ast_tools/src/generators/mod.rs | Adds module declaration and public export for OxlintEnvsGenerator with conditional compilation for JS generation |
| tasks/ast_tools/src/main.rs | Registers OxlintEnvsGenerator in the generators list with the generate-js feature flag |
| tasks/ast_tools/Cargo.toml | Adds javascript-globals dependency to the ast_tools workspace |
| apps/oxlint/src-js/generated/envs.ts | Generated TypeScript file containing environment definitions with interface and constants for each environment (e.g., browser, node, ES2015-ES2026, etc.) |
| Cargo.lock | Updates dependency graph to include javascript-globals for oxc_ast_tools |
| .github/generated/ast_changes_watch_list.yml | Adds the generated envs.ts file to the watch list for AST change detection |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1945761 to
61a792c
Compare
ba840df to
61868e3
Compare
d1cbc59 to
0e0b237
Compare
61868e3 to
8dce152
Compare
Merge activity
|
Generate a file defining the vars that each environment (`env`) provides. This isn't used for anything yet, but it will be in next PR #17293. Vars for each environment are stored in this form: ```js { readonly: ["var1", "var2", "var3"], writable: ["var4", "var5"], } ``` instead of the more obvious: ```js { var1: false, var2: false, var3: false, var4: true, var5: true, } ``` ...because it's shorter code when there's lots of vars (which there usually are), and iterating through arrays I assume is faster than iterating through properties of objects (which are essentially hash maps when they're large).
0e0b237 to
5cc7c90
Compare
8dce152 to
c9512a9
Compare
CodSpeed Performance ReportMerging #17292 will not alter performanceComparing Summary
Footnotes
|

Generate a file defining the vars that each environment (
env) provides.This isn't used for anything yet, but it will be in next PR #17293.
Vars for each environment are stored in this form:
instead of the more obvious:
...because it's shorter code when there's lots of vars (which there usually are), and iterating through arrays I assume is faster than iterating through properties of objects (which are essentially hash maps when they're large).