stylelint task should create default prettier config

MR created that adds the same steps to copy the prettier config as exists on the eslint script.

Hi tomtech,
Could you link to a failing stylelint job please?

I didn't know that styelint could also use the prettierrc.json and prettier.ignore files. But if that is the standard way to do it, then yes we should copy the core ones if the project does not have their own.

Setting to NW as I left a comment in the MR.

@jonathan1055,

Here is a link to a failed gitlab stylelint job.

https://git.drupalcode.org/project/commerce_paypal/-/jobs/6229973

I was able to fix it in the project by copying prettierrc.json from core/.

I copied the lines directly from the eslint job for consistency, but understandably, the line for .prettierignore can be removed. (We can't copy the one from core, as the paths wouldn't be correct.) I'll update the MR.

Thanks for the link to your failing test.

For reference the failing file is /css/paypal-fastlane.css

The core/.prettierrc.json file contains printWidth: 80. To test this MR and to provide ongoing test coverage, I will modify a css file in our Gitlab Templates Downstream → testing project.

I have replicated the problem in GTD. Oddly, the error does not display the full line, like in your job
It just shows that it wants a newline at 6:64 (which is correct) but the full text of the line is not shown.

The suggested newline is not correct.

I think you are overlooking a block in core/.prettierrc.json.

While printWidth is initially set to 80...a few lines down it is specifically overwritten for css files to be 10000, along with using a specific css parser.

See: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/.prettierrc.j...

Specifically, this override for css was added when stylelint configuration added a prettier configuration, along with using a specific css parser. See the commit here:

https://git.drupalcode.org/project/drupal/-/commit/1fbf9f5d2b589e17b7c67...

It's all fine. I editted my comments above, you probably saw the original in e-mail, sorry to add confusion.

I also noticed that the stylelint command has the hard-coded --config $CI_PROJECT_DIR/$_WEB_ROOT/core/.stylelintrc.json which means we are always using the core .stylelintrc.json. Do you think many/any projects have their own .stylelintrc.json ? Maybe we should change that, and do a link to the core link only if there no .stylelintrc.json in the project?

As far as this issue and this MR goes, things look good. Marking it RTBC unless you want to address what was mentioned in #10. That could be done here or in a follow-up issue if needed. Let me know if you want this to be merged as is.

Forgot to actually mark it RTBC.

Merged. Thanks!

Thanks for merging. Can we leave this issue open, as I think we should address #10. I need to check exactly how stylelint detects it's config file. If the first place it looks is in the current directory then we can simply do "if the project has no .stylelintrc.json in project root then create a link to the core file". Should be easy to test.

Cool. Back to "needs work" to try to address #10. The merged change was easy enough to go into "main".

According to the stylelint documentation there are multiple acceptable names for the config file, of which .stylelintrc.json is just one. So our job needs to check for any file starting stylelint.config or .stylelintrc and if none found then we link to the core file. That covers them all apart from if the config is specified within the project's package.json file. I doubt if many projects use that, and if they did then it is already not working for them in Gitlab Templates because we hard-code the core file. So this proposed change does not make that situation any worse.

First attempt failed, we can't link or copy the core file into the project folder because it contains paths that then become invalid:

Error: Could not find "stylelint-config-standard". Do you need to install the package or use the "configBasedir" option?
    at configurationError (file:///builds/project/gitlab_templates_downstream/web/core/node_modules/stylelint/lib/utils/configurationError.mjs:12:49)

So the alternative is to dynamically add the --config when it is needed.

MR399 is ready for initial review. The downstream jobs pass with no changes. The core file is still being used.

I have also tested it in GTD branch 3503337-mr-testing-d10-plus
Here is the starting point, from d10-plus with the added (very simple) stylelint.config.js config file in the project root
The job intentionally fails due to not allowing color names. You can see STYLELINT_CONFIG= is blank in the log because the project has it's own stylelint.config.js

Then modify the local file to use color names and the job passes. This demonstrates that the local config (if is exists) is active and controls the result of the job.

There are two lines of debug to remove, but this is ready for review