feat: RuleEnhancer & unwrapped POJOs rule#2127
Open
aleksanderkatan wants to merge 9 commits intofeat/type-aware-lint-plugin-pocfrom
Open
feat: RuleEnhancer & unwrapped POJOs rule#2127aleksanderkatan wants to merge 9 commits intofeat/type-aware-lint-plugin-pocfrom
aleksanderkatan wants to merge 9 commits intofeat/type-aware-lint-plugin-pocfrom
Conversation
|
pkg.pr.new packages benchmark commit |
📊 Bundle Size Comparison
👀 Notable resultsStatic test results:No major changes. Dynamic test results:No major changes. 📋 All resultsClick to reveal the results table (335 entries).
If you wish to run a comparison for other, slower bundlers, run the 'Tree-shake test' from the GitHub Actions menu. |
There was a problem hiding this comment.
Pull request overview
This PR introduces a reusable RuleEnhancer system for ESLint rules and implements a new unwrapped-pojo rule that enforces wrapping Plain Old JavaScript Objects in schema calls within 'use gpu' functions.
Changes:
- Adds
enhanceRuleutility that allows rules to compose reusable visitor-based enhancers for collecting contextual data - Implements
directiveTrackingenhancer to track function-scoped directives like 'use gpu' - Introduces
unwrapped-pojorule that flags unwrapped object literals in 'use gpu' functions
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/eslint-plugin/src/enhanceRule.ts | Core enhancer system with visitor merging logic that enables composable rule behavior |
| packages/eslint-plugin/src/enhancers/directiveTracking.ts | Tracks whether code is inside a function with specific directives using a scope stack |
| packages/eslint-plugin/src/rules/unwrappedPojos.ts | Rule implementation that uses directiveTracking to flag unwrapped objects in 'use gpu' functions |
| packages/eslint-plugin/tests/unwrappedPojos.test.ts | Comprehensive test coverage for various function types and directive scenarios |
| packages/eslint-plugin/src/configs.ts | Registers the new rule in both recommended and all configurations |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
Author
|
We need to filter out functions located inside createRenderPipeline due to autostructs. |
aleksanderkatan
force-pushed
the
feat/lint-unwrapped-pojos
branch
from
f24b760 to
7c91882
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Blocked by #2097
The rule introduced in this PR requires context - it is only relevant when the current function has a 'use gpu' directive.
I saw three potential solutions:
While 1. seems like the simplest solution, I didn't like it due to potential long chains of lookups (options 2. and 3. always returns answers in constant time).
Option 2. is, to my best knowledge, impossible, though I didn't find any concrete info on this. There seems to be no built-in api like that in eslint (the context only holds static informations), and the rules are supposed to be able to run in parallel. You can even run one rule on multiple threads (the number printed out is a "global" variable).
Maybe a file-scoped context could exist? I found no information on this. And as long as our rules are lightweight, I don't think we should care.
So I came up with a way of "enhancing" rules with data collectors. In short, we can first define a
RuleEnhancer-- a visitor that collects some data and exposes access to it, and merge it into a visitor. This way code is clean and composable -- we can reuse the 'use gpu' lookup in a new rule without any effort.Lookup version (1.):
'Enhancing' api (3.):