Closed ian-svoboda-prom closed 1 year ago
Hey @ian-svoboda-prom !
I think this is not an issue anymore. This used to happen when using custom-property-pattern
which is not included in our package, WordPress, stylelint-recommended or stylelint-recommended-scss.
Could you ensure your dependencies are up to date? I've checked on a couple of projects and though I've battled with this in the past, it doesn't seem to be brought up again by the linting nowadays.
Please let me know if you find something that could be fixed as I agree this would not be ideal
@ian-svoboda-prom Is this still an issue? Do you have a custom stylelint config?
Hello,
@nicholasio can confirm this is still an issue. Running into it right now for a project using v5.2.1.
@ian-svoboda-prom if possible can you share an example to bypass this if possible.
@JacksonCleary please can you provide mor information? We've been checking on some projects and couldn't replicate, would love to get to the bottom of this issue
@Antonio-Laguna can confirm a warning is still thrown even with zero configuration and the latest toolkit version. The screenshot here shows the package.json file, my terminal output, and the code in question:
Basically it warns about kebab-case due to the custom-property-pattern rule, which you've said shouldn't actually be here. So that seems to suggest that something else is included that in their ruleset. You can see from this screenshot that I'm not doing things like customizing stylelint or the webpack config, it's a super barebones theme that I was creating just for the purpose of using 10up-toolkit (for a blog post).
I used node 18 when running the start command here, but I also replicated running node 16, so I doubt that's related.
Let me know if you have any other questions.
@JacksonCleary The solution here is to add your own .stylelintrc
config file to the theme root and then exclude a given rule, here's an example of what that file might look like:
{
"extends": [
"@10up/stylelint-config"
],
"rules": {
"custom-property-pattern": null,
}
}
I hope that helps!
Thanks! Was able to find this! will prepare a PR soon
@Antonio-Laguna
I don't know if it being inherited somewhere else, but we still need to support BEM conventions:
block
block__element
block__element--modifier
block-test__element
block-test__element--modifier
This should work for all of them - I think (although I'm not an expert): ^(?:--\w+(?:[-_]\w+)*(?:--\w+(?:[-_]\w+)*)*|(?:\w+(?:__\w+)*(?:[-_]\w+)*(?:--\w+(?:__\w+)*(?:[-_]\w+)*)*)+)$
@joesnellpdx This change only affects custom property names and not selectors
Is your enhancement related to a problem? Please describe.
The current stylelint configuration has a rule that requires kebab-case variables. So if you attempt to use a CSS variable that is generated by WP (ex: theme.json color palette choices) it will throw an error because those variables use a double-hyphen (--) deliminater, such as:
--wp--preset--color--white
.It seems clunky to have to create a secondary "alias variable" just to get around this, so for now I've just disabled the rule in the stylelint configuration.
Perhaps there's a way to set up the pattern matching to look for variables prefixed by
--wp--
and allow those while enforcing the current pattern for custom ones? That might be a way to have our cake and eat it too.Designs
No response
Describe alternatives you've considered
There are only a few options:
Code of Conduct