-
-
Notifications
You must be signed in to change notification settings - Fork 929
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 validateTypes
to stylelint.utils.*
#5669
Comments
Since the utils are private and cannot be changed easily in the future, it seems not good to me to expose them. 🤔 |
We'll need to weigh up the convenience for plugin authors against the costs of a broader public API for ourselves. We expose 4 utils:
There are other utils that are stable in responsibility, e.g. the There's no obvious right answer here, we'll need to pick what we think is the best compromise. |
Example of the (As an aside, it looks like a new version of the validator is going to land soon with support for at-rules!) |
Interesting. Exposing such helper functions may be valuable...?
This is very promising! 🙌🏼 |
validateTypes
utilsvalidateTypes
to stylelint.utils.*
Let's expose We can revisit the |
I'm reconsidering this issue inspired by #6151. What if starting with the following changes?
|
Adding only the Having said that, I'm not 100% sure of the value of exposing these compared to the reference data which will change over time whereas the type checks won't. A person can, if they wish, copy and paste them into their plugin confident that they are unlikely to change. |
I also have the same concern. Again, the more we expose, the more we have to think about when releasing. |
Closing in favour of broader discussion issue #6866 |
It would probably make sense if the validateTypes were exposed for downstream packages to consume.
Refs stylelint-scss/stylelint-scss#554
EDIT: looking at stylelint-scss code, it seems they duplicate a lot more utils.
The text was updated successfully, but these errors were encountered: