-
Notifications
You must be signed in to change notification settings - Fork 0
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
Should we add other types of downstream plugins? #60
Comments
These are packages that run Stylelint for you, integrated into some other tool or task runner, right? If these are testable and add meaningful coverage, then sure :) |
|
Same answer I guess :) The goal of the project (as I understood it) is to make rolling out releases safer and more controlled. We try to attain that goal by testing downstream dependents so that unexpected side-effects of changes can surface before a release. I don't think we need to test every or even many downstream dependents. By testing a few downstream dependents, those that are simple and easy to test, we gain a lot of assurances before a release. But the returns diminish sharply with each extra package we test. If something can be trivially added to the existing list and adds some meaningful test coverage, then that is always nice. If something is complex then I think we might want to avoid adding it here. |
Then let's add the ones that have tests for now. off-topic I am kind of surprised that we don't have an unplugin-stylelint. |
e.g. stylelint-webpack-plugin, vite-plugin-stylelint, esbuild-plugin-stylelint, etc.
stylelint-webpack-plugin
nx-stylelint
The text was updated successfully, but these errors were encountered: