-
Notifications
You must be signed in to change notification settings - Fork 3
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
Integration with stylelint. #9
Comments
This sounds like a great plan to me, both in terms of the API for a |
Agreed. Sounds great! We were anticipating the stylelint plugin being called |
@jeddy3 Did you mean Ignoring things like string interpolation and variables in the consuming plugin is probably easiest, but it might be worth adding support still as long as this behaviour was opt-in. That facilitates this use case; h1 {
color: hsl($hue, $sat, $light, $alpha); // Error: Too many arguments passed to `hsl`. Expected 3.
} Although, it shouldn't try to validate mixins that are not part of CSS syntax. I'd like validation to occur on a property/value pair, and leave more sophisticated static analysis up to other plugins. Personally I am not using Sass syntax so I would welcome support for this feature from somebody who would be willing to maintain this. |
Ha, yes I did :)
That would be nice.
Same. Hopefully someone will step up though. |
0.1.0 is now out on npm if you'd like to have a play with it. 😄 |
#26 is also really relevant for stylelint's use case. 😄 |
This follows on some thoughts I had in the stylelint chat.
/cc @stylelint/core
So, I believe that the primary use case for this project is to provide meaningful feedback to a developer about incorrect CSS, and so stylelint is the best fit for it. Of course, I have my own use case of being able to check validity of CSS properties before merging, but primarily I think stylelint benefits the most from this work. With this in mind, I think we need to discuss how we can integrate this into stylelint!
I am now thinking of not exposing any of the templating/generation that we do in the background, it's just not necessary for the two main use cases that I've outlined (and, it took me a while to see @davidtheclark's logic for not doing this). Instead, css-values will exist as a module on npm which you can require, and won't do any CSS parsing beyond using postcss-value-parser; you will be able to use it to return a warning message or
true
if the value passed validation.To facilitate this I think we need to move to a monorepo which houses:
One of the areas that I've already identified as needing improvements is the lack of feedback from the module on an invalid value. It seems like something that can be addressed fairly easily by changing the return value (in the invalid case) of a lot of the different validator functions. So, if you'd like to contribute then this is a really good way to do so!
Please let me know if you have any questions/suggestions/feedback, it really helps! 😄
The text was updated successfully, but these errors were encountered: