-
Notifications
You must be signed in to change notification settings - Fork 878
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
[eslint-plugin] Add attribute names rule #4516
Conversation
🦋 Changeset detectedLatest commit: 5adce21 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultsthis-change
render
update
update-reflect
this-change, tip-of-tree, previous-release
render
update
nop-update
this-change, tip-of-tree, previous-release
render
update
this-change, tip-of-tree, previous-release
render
update
update-reflect
|
The size of lit-html.js and lit-core.min.js are as expected. |
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.
Commenting minor things that stood out to me. I'll defer to other reviewers for the actual rule implementation.
Additionally noting that packages like labs/cli and labs/compiler that have direct dependency on typescript will also need version bumps with this.
It is curious that this has size regression for core packages. Could changing the TS version change the emitted JS? |
@augustjk I was wondering the same thing 🤷♂️ |
i would have two rules i think, a typed and untyped one (which share some logic). then just publish a typed/untyped recommended config
sounds good to me. i'm not too concerned with the copyright, copying things over here, etc. as long as im still able to exist as a maintainer alongside you all (which it seems i am) |
package-lock.json
Outdated
@@ -21614,9 +23667,10 @@ | |||
} | |||
}, | |||
"node_modules/rollup-plugin-terser/node_modules/terser": { | |||
"version": "5.19.2", | |||
"version": "5.27.0", |
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.
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.
looks good to me 🥳
messageId: 'casedPropertyWithoutAttribute', | ||
}, | ||
], | ||
}, |
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.
Huh, I hadn't seen this rule before. Do we like this rule? Do we want to recommend it?
The casedAttribute message seems good, but the casedPropertyWithoutAttribute doesn't seem great to me.
At least, I see a lot of unproblematic code that would trigger this lint.
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.
https://github.com/43081j/eslint-plugin-lit/blob/master/docs/rules/attribute-names.md
I'm planning on porting all the existing rules to ease migration to the new version. I'm sure there is some overlap with Rune's rules, and some we might want to deprecate going forward. I agree that a lot of perfectly fine code may have a camelCased property name and be making the choice to use the lower-case / case insensitive attribute name and shouldn't be flagged. In those cases we may want additional configuration for this rule, and we may want a migration-oriented configuration and not include this in the recommended set.
I should open an RFC on how the plan for all of this.
'--disable-input-event-activation-protection', | ||
'--disable-renderer-backgrounding', | ||
'--enable-automation', | ||
'--disable-ipc-flooding-protection', |
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.
where did these new flags come from?
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.
I found these in a few places that were documenting trying to work around Chrome's background tab throttling. I'm trying to separate and/or revert the changes causing the problems to unblock this PR.
export const rules = { | ||
'no-kevin': noKevin as unknown as Rule.RuleModule, | ||
}; | ||
export const rules = {}; |
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.
Should this be empty?
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.
nope!
9ec8c61
to
348ee0f
Compare
Co-authored-by: Augustine Kim <augustinekim@google.com>
348ee0f
to
5adce21
Compare
This PR should be easier to review commit-by-commit. The last commit adds the actual attribute-names rule, the rest of them set things up. I bumped typescript and a few testing dependencies due to package duplication that broke the build while installing some packages.
Type-awareness
This implementation of attribute-names requires a type-checker. This is to detect Lit subclasses and decorators. I think this is a good tradeoff for now, especially as we can support subclasses, ReactiveElement, re-exports, etc (work on that TBD). We almost certainly do want to be able to use different heuristics to detect these things in places where they don't want to run the type-checker, so we can make some detection logic pluggable.
typescript-eslint recommends an option or two different rules in this case:
https://typescript-eslint.io/developers/custom-rules/#typed-rules
We'll have to figure that out.
Copyright assignment
@43081j I originally copied the rule from https://github.com/43081j/eslint-plugin-lit/blob/master/src/rules/attribute-names.ts but ended up rewriting most of it to work against the Lit analyzer. I did copy the tests, then added the correct Lit imports to satisfy the analyzer's detection of LitElement and decorators.
The commits to this repo need to be copyright Google (unless they're a compatible OSS license, credited, and linked). I think the rule implementation qualifies. The test is written by you and you've signed the CLA, so I believe you can just reassign copyright to Google at will with your approval here. Or I can write new tests if necessary.