Follow-up to #2865971: Use stylelint as opposed to csslint in core. This adds stylinelint config - let's use it in DrupalCI. It much better for our purposes since core patches can update it and add plugins.
All the commands below take place in DRUPAL_ROOT/core
To install stylelint
yarn install
This will install Drupal 8's node JS dependencies of which stylelint is one.
To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core
yarn run lint:css
Make DrupalCI use yarn to install dependencies and run linting - hopefully it is already doing that for eslint.
None
tdb
Comments
Comment #2
mile23How does this map out to contrib?
Comment #3
alexpottIn my mind contrib should ship with a package.json too and declare their dependencies - which means we should really publish our eslint and stylelint rules too. At some point a module author ought to be able too use modern frontend techniques to compile es6 to js and what css processor they like - they shouldn't need to commit the output - DrupalCI etc should build it out for people.
However - at the moment this situation is no different from csslint or eslint - there's a .stylelintrc.json in root and if a module doesn't have it's own stylelint config we should use that. If it does we should use theirs.
Comment #4
mile23Substitute yarn instead of npm in the IS, right?
Comment #5
alexpottYep!
Comment #6
alexpottThis is good to go now! So we need to get yarn on the build boxes and then we can run the
lint:css-checkstylecommand to lint our files.Comment #7
mile23Postponed on #2874028: Create a Yarn Build step
Comment #8
Mixologic#2874028: Create a Yarn Build step is done, so, unpostponing.
Comment #9
MixologicHad several talks with folks.
A. There's no global "Drupal" standard anywhere yet. Just the rules that core currently complies with in /core
B. We should only run this for a contrib project if they put a stylelintrc.json file in their project. Otherwise we should skip linting. Im +1 on this. We can change that later.
C. There will, eventually, be a stylelint global standard, and we'll keep it somewhere like drupal/css-coding-standards on github, add it to packagist, and point maintainers at that as a starting place.
theres a --fix option which I think I'll treat under the same policy we have for phpcs rules. seee (https://www.drupal.org/project/drupalci_testbot/issues/2912074)
Comment #11
MixologicTurns out there is not a --fix option yet. not until https://www.drupal.org/project/drupal/issues/2910706 goes in.
Which means, we might want to do some sort of capabilities checking. If we can --fix, then we do it.
some scenarios to handle:
with and without the existance of --fix
test_autofixed_patch/generate the resultant patch +interdiff of what was autofixed
Core vs contrib
with/without stylelint.rc
with/without changes to stylelint.rc in patch
with/without changes to css files.
patch can add, remove, modify, or leave untouched .stylelintrc
project can either have, or not have .stylelintrc after codebase building.
Patch can either change css files or not.
the testrun itself can either have issues or not
if it has issues it can run --fix to fix those issues - maybe twice depending.
Comment #12
MixologicComment #13
MixologicThis is posponed on https://www.drupal.org/project/drupal/issues/2910706
Comment #14
joelpittetUnblocked
Comment #15
Mixologic+++ awesome
Comment #16
jonathan1055 commentedAny update on this? My contrib projects have CSSLINT coding standards faults, but if that is not being used in core, in favour of STYLELINT then I'd like to be able to run stylelint in drupal ci testbot runs instead.
Comment #17
joelpittetgitlab-ci is the successor, I don't believe this is relevant (cleaning up issues I was following)
Comment #18
jonathan1055 commentedThanks, yes csslint is not run in GitLab CI, we have Stylelint instead. Thanks for the tidy-up.