-
Notifications
You must be signed in to change notification settings - Fork 815
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 stylelint #11767
Add stylelint #11767
Conversation
Hmm, Also, let's ideally include Calypso's |
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: April 2, 2019. |
I was thinking it should be a separate package just like for eslint? Here I copypasted it just for the proof of concept. |
Caution: This PR has changes that must be merged to WordPress.com |
This is an automated check which relies on |
@Automattic/jetpack-crew a question: which ruleset should Jetpack follow for linting scss files — You can see the difference roughly by first running I didn't dig deep yet to differences but brackets spacing seems different at least:
There's no big difference in maintenance from Jetpack point of view — both would be external configs Jetpack would just consume and use. I think it's also possible to layer them by using WordPress as a base and Calypso on top of it. |
Caution: This PR has changes that must be merged to WordPress.com |
@jeherve @kraftbj do you have an opinion which Stylelint config to use for Jetpack? I would suggest sticking to the core one. See #11767 (comment) |
simison, Your synced wpcom patch D33725-code has been updated. |
1 similar comment
simison, Your synced wpcom patch D33725-code has been updated. |
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, somehow I missed this PR before. I like it!
I would suggest sticking to the core one.
I would vote for sticking to the Core one too.
package.json
Outdated
@@ -192,13 +196,16 @@ | |||
"mockery": "2.1.0", | |||
"nock": "10.0.6", | |||
"node-wp-i18n": "1.2.3", | |||
"npm-run-all": "4.1.5", |
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 need to introduce a new dependency here, instead of just chaining the different actions?
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.
We can totally just chain them but it should be faster to run in CI in parallel. How much faster — I'd have to check. :-)
I wonder if it would make sense to add php:lint
script to the same run? (That would be good for another PR anyway)
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, if it is faster we should probably start using it everywhere we can :)
But we can do that in another PR indeed.
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, I'd like to see some exploration adding parallelism to build steps for instance.
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.
Noting that we started using concurrently
for some of our tasks; maybe we could use it here too?
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 ye, totes agreed! Feel free to change unless I get to it first.
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.
@jeherve switched to concurrently
simison, Your synced wpcom patch D33725-code has been updated. |
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.
This works for me. Tests are failing right now though:
https://travis-ci.org/Automattic/jetpack/jobs/596002607
Yeah, that's a weird one. I don't understand why and I was suspecting it was because of how React version got resolved from Full error:
|
Late to the party, but agreed with sticking with Core. |
This PR has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this PR has clear testing instructions, is it up to date with master, and it is still valid. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
fd93724
to
69a7ba8
Compare
@jeherve looks like this didn't get merged last time it was ready — I rebased it to new folder structure and switched to new core package. Ready to go on my behalf! :-) |
0e416a1
to
af7dd17
Compare
Works just fine without but wanted to keep all `concurrently` calls more consistent
af7dd17
to
523a342
Compare
@jeherve rebased. I've switched to Let's get this long timer in? :-) |
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 ok as far as it goes. A few nitpicks inline.
But if we're going to add this, we should fully add it. There's not a whole lot of point in adding linting if no one pays any attention to it.
- The pre-commit hook (tools/git-hooks/pre-commit-hook.js) should probably run it like it does phpcs and eslint.
- CI should run it too.
- And both of the above would likely want a tool like our eslint-changed and logic like our excludelists so as to not bomb everyone with 10281 warnings all the time. Or else someone needs to fix the 10281 warnings it currently reports 😉.
Is that on anyone's radar?
"reformat-files": "yarn prettier --ignore-path .eslintignore --write \"**/*.{js,jsx,json}\"", | ||
"reformat-files": "yarn concurrently 'yarn:reformat-files:*'", | ||
"reformat-files:js": "yarn prettier --ignore-path .eslintignore --write \"**/*.{js,jsx,json}\"", | ||
"reformat-files:scss": "yarn lint:scss --fix", |
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.
It sounds like a --fix is going to do more than just reformat...
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.
Neither Prettier nor Stylelint changes actual functionality so I think it's exactly reformatting, but I'm no native speaker. :-)
The command was to follow existing convention from Calypso repo.
Not a biggie to use something else here, tho!
@@ -59,14 +59,18 @@ | |||
"docker:update-core-unit-tests": "yarn docker:compose exec wordpress svn up /tmp/wordpress-develop/tests/phpunit/data/ /tmp/wordpress-develop/tests/phpunit/includes", | |||
"docker:wp": "yarn docker:compose exec wordpress wp --allow-root --path=/var/www/html/", | |||
"install-if-deps-outdated": "yarn install --check-files --production=false --frozen-lockfile", | |||
"lint": "yarn lint-file .", | |||
"lint": "yarn concurrently 'yarn: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.
The resulting output isn't very human-friendly. In a few places it even has lines from the different linters interleaved.
This is pretty old and Jetpack structure is way different these days. I'll close and anyone feel free to re-open/pick code and continue. |
Adds linting for SCSS files, using WordPress core ruleset.
TODO in follow up PRs:
yarn reformat-files
handles a lot of them,Changes proposed in this Pull Request:
package.json
scripts to use it.Testing instructions:
yarn lint:scss
/yarn lint
yarn reformat-files:scss
/yarn reformat-files
Proposed changelog entry for your changes: