-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Add more ESLint recommended rules, and enforce them in CI. #373
Conversation
This reverts commit 82d2ce9.
* main: More consistent formatting across the codebase. (color-js#372) More accurate ICtCp matrices (color-js#365) Fix Jzazbz tests (color-js#366)
✅ Deploy Preview for colorjs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
Thanks so much!
Main issues are:
- I'd rather avoid black boxes of rules like
eslint:recommended
, and list the rules we want explicitly - I know it's a lot of work, but it would be very useful if we could add comments above rules with obscure names (even for those with non-obscure names I find myself wondering about the specific, e.g.
keyword-spacing
is obvously about keyword spacing, but what kind of spacing does it enforce?). Is there something that could automate this perhaps?
Presumably we can still merge something even if CI fails, right? Something worth exploring might be to only fail CI for the more egregious violations and not all style rules.
.eslintrc.cjs
Outdated
}, | ||
"env": { | ||
"browser": true, | ||
"es6": true, |
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.
Rather than specifying a specific version, is there a way to say "the newer version supported"?
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.
The purpose of this is to tell ESLint what predefined global variables are assumed to be available. My understanding is that Color.js supports down to Node v12 with legacy builds, and Node v16+ with the base build (and equivalent browsers). We could safely update this e.g. es2020
based on that -- but it also doesn't hurt for this to be a lower version unless/until we start using cutting-edge ES functionality.
I'll update to es2020
for now. (I don't think there's a way to make this a dynamic value, no.)
https://eslint.org/docs/latest/use/configure/language-options#specifying-environments
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'd rather avoid black boxes of rules like
eslint:recommended
, and list the rules we want explicitly
Adjusted in da191b1
- I know it's a lot of work, but it would be very useful if we could add comments above rules with obscure names (even for those with non-obscure names I find myself wondering about the specific, e.g.
keyword-spacing
is obvously about keyword spacing, but what kind of spacing does it enforce?). Is there something that could automate this perhaps?
Added in 93bfb52
Presumably we can still merge something even if CI fails, right? Something worth exploring might be to only fail CI for the more egregious violations and not all style rules.
Yes, we can still merge if CI fails. If we decide some rules are worth CI failures and others aren't, the simplest solution would be to mark the high priority ones as error
and tell CI to only fail on errors.
order: var(--c); | ||
} | ||
|
||
@nest [data-order="h"] & { | ||
[data-order="h"] & { |
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.
These were causing deprecation warnings.
@@ -5,7 +5,7 @@ | |||
{ | |||
"targets": "defaults, node >= 12", | |||
"useBuiltIns": "usage", | |||
"corejs": "3.25" | |||
"corejs": "3.30" |
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.
Updated to match the current installed version, as recommended by Babel.
"lint": "run-s \"eslint -- --fix\" dtslint", | ||
"lint:ci": "run-s \"eslint -- --max-warnings 0\" dtslint", |
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.
Locally npm run lint
will pass, but display warnings. In CI, lint warnings will cause CI to fail.
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.
Sorry for the delay, and thanks again so much for this work. Amazing stuff. I think once we're done with this, I'll use this eslint file across my other repos too!
I've left a few comments. I didn't check the TS rules, as long as you and @MysteryBlokHed have consensus on these, feel free to use whatever.
As a general point, I'd love it if we could put the explanatory comments above the rule they describe, so we could have space to also include a link (e.g. https://eslint.org/docs/latest/rules/no-unsafe-optional-chaining or https://eslint.style/rules/default/brace-style ). Even with the comments, I still had to look up a lot of these rules to understand what they did, and having clickable links would have been very convenient. But also, I'm wary of asking you to do more work for this, so take this as a non-blocking suggestion. :)
Hi @jgerigmeyer, I’m quite eager to merge this, how could I help? |
@LeaVerou Sorry for the delay! I've been swamped with travel and work. I'll prioritize this Monday morning 👍🏻 |
* main: Add CAM16 (JMh) (color-js#379) [spaces/prophoto] Use 64 bit-accurate conversion matrices formatting [spaces/hsl] Better handling of negative saturation on very oog colors Point to the actual, working tests not the old ones CSS4 toGamut fixes (color-js#352)
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.
As a general point, I'd love it if we could put the explanatory comments above the rule they describe, so we could have space to also include a link.
Added in cae6066
But also, I'm wary of asking you to do more work for this, so take this as a non-blocking suggestion. :)
Not a problem! Sorry for the delay.
@@ -195,7 +195,7 @@ export function fromCam16(cam16, env) { | |||
hRad = constrain(cam16.h) * deg2rad; | |||
} | |||
else { | |||
h_rad = invHueQuadrature(H) * deg2rad; | |||
hRad = invHueQuadrature(cam16.H) * deg2rad; |
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.
@facelessuser I am not confident in these changes, but the new lint rules highlighted that h_rad
and H
were both undefined here. Can you clarify the intention?
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.
Yeah, h_rad
was a typo on my part, it should be hRad
as you've done. We aren't currently generating the reverse transform with hue quadrature, so this wasn't caught.
H
is not likely to be undefined as we check to make sure h
or H
is defined on line 183. So one of them must be defined at this point, but it may confuse the checker.
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.
Thanks! So it sounds like this is good to go.
H
is not likely to be undefined as we check to make sureh
orH
is defined on line 183. So one of them must be defined at this point, but it may confuse the checker.
H
was undefined (likely a typo) -- this changes it to cam16.H
, which is defined.
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.
Oh, H
was undefined! 🤦🏻 Sorry, this all looks correct.
@LeaVerou Updated and ready for another round of review! |
src/util.js
Outdated
@@ -241,7 +241,7 @@ export function zdiv(n, d) { | |||
* @param {number} hi - used to specify a the high end of a subset of the list | |||
* @returns number | |||
*/ | |||
export function bisectLeft(arr, value, lo=0, hi=arr.length) { | |||
export function bisectLeft (arr, value, lo=0, hi=arr.length) { |
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.
Non-blocking but we may want to add a rule that the =
here needs spaces around it.
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.
LGTM! Just a rebase needed to remove this README.html
Please make sure to squash-merge since there are a lot of commits.
Thanks again so much for working on this!!
* main: Do not generate a tests/README.html! Add functions to convert old tests to new tests
There was nothing specific about that |
@LeaVerou The three rules I added are:
I think they're pretty straightforward and I've looked carefully through the resulting code changes and don't see any issues, but if you prefer I can remove them. |
Ok, let's merge this! 🚀 |
A replacement of #351 and #367.
Right now CI will fail if there are any lint errors or warnings.
Very open to feedback and/or rules changes!