-
Notifications
You must be signed in to change notification settings - Fork 7
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
chore/Issue-51: Refactor lint-staged config #112
Conversation
✅ Deploy Preview for super-tapioca-5987ce ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for super-tapioca-5987ce ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
package.json
Outdated
"*.js": "npm run lint:js", | ||
"*.css": "npm run lint:css", | ||
"**/*": "npm run lint:ls && npm run format" | ||
"*.js": [ |
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.
Interesting, didn't know about the array syntax, that makes sense. I get the --
part but curious how it works for say this case?
# before
"*.css": "npm run lint:css",
# after
"*.css": "npm run lint:css --",
How come we would need the --
here? Does this imply format
is being run implicitly and so needs to be chained in each entry in the lint staged config?
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.
Honestly, I'm not totally clear with why the --
is needed. It was listed in the examples so I assume it's something within lint-staged
that requires 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.
With npm
you use the --
to forward arguments in npm scripts, like here
https://github.com/thescientist13/gallinago/blob/master/package.json#L30
"test": "c8 node --debug-port 3333 ./node_modules/mocha/bin/mocha",
"test:tdd": "npm test -- --watch"
I'm wondering if this just enabling some sort of catch-all forwarding here?
Let me give this a dry run in a couple days |
package.json
Outdated
"npm run format --" | ||
], | ||
"*.css": "npm run lint:css --", | ||
"*.*": "npm run lint:ls --" |
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.
just making sure I understand, but this change looks like it would not be running Prettier anymore on all files, just JS files? Is there any way we could keep that previous behavior of formatting all files?
I think this should preserve the existing intentions while also accounting for the best practices you've applied here?
"lint-staged": {
"*.js": "npm run lint:js --",
"*.css": "npm run lint:css --",
"*.*": [
"npm run lint:ls --",
"npm run format --"
]
}
Related, but I think I may have made a mistake in the original Stylelint configuration, in that it looks like we are still honoring stylistic rules with the plugin I installed (was not my intention), which we shouldn't be doing since that's the whole point with Prettier (seem obvious in hindsight 😅 ).
This also causes tension in our lint staged as it commits the faux pax of having multiple tools trying to enforce / report style rules. (I had setup ESLint to ignore style rules and that looks to be behaving as expected)?
➜ www.greenwoodjs.dev git:(issue-51-resolve-lint-staged) ✗ git commit -m "fix styles" ✔ Preparing lint-staged... ⚠ Running tasks for staged files... ❯ package.json — 2 files ↓ *.js — no files ❯ *.css — 1 file ✖ npm run lint:css -- [FAILED] ❯ *.* — 2 files ✔ npm run lint:ls -- ✖ npm run format -- [KILLED] ↓ Skipped because of errors from tasks. ✔ Reverting to original state because of errors... ✔ Cleaning up temporary files...✖ npm run lint:css --: src/styles/theme.css 23:7 ✖ Replace "·" with "⏎" prettier/prettier ✖ 1 problem (1 error, 0 warnings) > [email protected] lint:css > stylelint "./src/**/*.css" /Users/owenbuckley/Workspace/project-evergreen/www.greenwoodjs.dev/src/styles/theme.css ✖ npm run format --: > [email protected] format > prettier . --write /Users/owenbuckley/Workspace/project-evergreen/www.greenwoodjs.dev/package.json /Users/owenbuckley/Workspace/project-evergreen/www.greenwoodjs.dev/src/styles/theme.css
I think what I should have done is install stylelint-prettier-recommended which now also benefits from actually catching some lint errors lol 🙃
➜ www.greenwoodjs.dev git:(issue-51-resolve-lint-staged) ✗ npm run lint:css> [email protected] lint:css > stylelint "./src/**/*.css" src/components/capabilities/capabilities.css 44:1 ✖ Expected selector ".active strong" to come before selector ".section:hover strong" no-descending-specificity 70:1 ✖ Unexpected duplicate selector ".heading", first used at line 12 no-duplicate-selectors 88:1 ✖ Unexpected duplicate selector ".sections", first used at line 21 no-duplicate-selectors src/components/copy-to-clipboard/copy-to-clipboard.css 7:3 ✖ Unexpected duplicate "background-color" declaration-block-no-duplicate-properties src/components/footer/footer.module.css 14:3 ✖ Unexpected shorthand "flex" after "flex-basis" declaration-block-no-shorthand-property-overrides src/components/hero-banner/hero-banner.module.css 90:3 ✖ Unexpected duplicate "display" declaration-block-no-duplicate-properties 94:3 ✖ Unexpected duplicate "vertical-align" declaration-block-no-duplicate-properties src/components/side-nav/side-nav.module.css 69:3 ✖ Expected selector ".compactMenuSectionHeading a" to come before selector ".compactMenu no-descending-specificity a:hover" 74:1 ✖ Unexpected duplicate selector ".compactMenuSectionHeading", first used at line 66 no-duplicate-selectors 95:3 ✖ Expected selector ".compactMenuSectionListItemActive a" to come before selector no-descending-specificity ".compactMenu a:hover" src/components/header/header.module.css 111:1 ✖ Expected selector ".mobileMenuListItem a" to come before selector ".navBarMenuItem no-descending-specificity a:hover" ✖ 11 problems (11 errors, 0 warnings) 3 errors potentially fixable with the "--fix" option.
So with all that said, I think we're pretty close to get this setup properly
- Swap out stylelint-prettier/recommended (config and dependency) with stylelint-config-recommended in stylelint.config.js
- Fix up any new CSS linting checks / sanity test UI
- tweak link staged tasks to reflect original intent + best practices
- (bonus / optional / whatever) put lint-staged config in its own config file
I've been able to make a good portion of the lint changes, but struggling with the last 4. These validations that mention the It seems that even though an element (ie: a given
|
Hmm, yeah. It wouldn't be inaccurate to say that some of these styles were written a little hastily at the time. 😅 I would make a best guess attempt at trying to consolidate on the called out styles, likely deferring to the most specific / nested selector element where possible, assuming it still works and looks the same. Otherwise, maybe it could just be a limitation of the tool not knowing our HTML well enough, but more likely just some sloppy CSS. Otherwise, I am happy to create an issue to specifically capture these specific items on their own so we can at least land this and have proper linting going forward for all net new code. |
8be3061
to
71a56b2
Compare
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.
Sweet! Did a quick test of the site and things are looking good, will do a more thorough check a little later on.
Left a couple feedback items but otherwise I think this one will be good to go on my next review. 👍
lint-staged.config.js
Outdated
@@ -0,0 +1,5 @@ | |||
export default { | |||
"*.js": ["npm run lint:js --", "npm run format --"], |
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.
Seems like by adding npm run format
to both globs now, would it would now be running twice, at least for JS files?
Is it possible to keep format
applied only to the wildcard glob?
@@ -1,6 +1,3 @@ | |||
export default { | |||
// no stylelint 16 support yet | |||
// https://github.com/developer-stylechain/stylelint-a11y/issues/4 | |||
// plugins: ['stylelint-a11y'], |
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.
do we know have access to the a11y rules? otherwise, we can should leave this comment in as a reminder, or maybe its just time to make a formal issue for tracking.
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, yeah I can revert this, or update to include our own issue, if you prefer.
As for the support, it looks like the issue that you have linked above is (now) closed and has a comment with a resolution of using 2 other libraries instead of the developer-stylechain
project.
Styleline v15 -> https://www.npmjs.com/package/@ronilaukkarinen/stylelint-a11y
Styleline v16 -> https://www.npmjs.com/package/@double-great/stylelint-a11y
Did you want me to attempt to include that plugin here in this PR? Happy to try, and could spin off a new PR if things got messy, if that's cool.
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.
Did a run through and looks good! Just made a small tweak to the lint-staged config and a follow up issue for #119
Thanks for another great PR!
Related Issue
Fix #51
Summary of Changes
Some Notes on lint-staged:
--
" - https://www.npmjs.com/package/lint-staged/v/12.3.2#reuse-npm-script/
will change how the glob works to identify the files. - https://www.npmjs.com/package/lint-staged/v/12.3.2#filtering-filesError Report
This is after the
stylelint-config-recommended
updateFrom comment #112 (comment)