rfcs
rfcs copied to clipboard
emberjs
Add Stylelint To Ember Blueprints
I recently removed Stylelint from our applications at Precision Nutrition. There was significant push back from our team on this tool. We found that:
- Setting up Stylelint to work with our existing stack was non-trivial. We have a fairly old, and complicated, PostCSS setup that necessitated a fair bit of massaging to appease Stylelint.
- Resolving conflicts was non-trivial for our existing, and large, CSS code base.
- Stylelint's TODO functionality is poor comparative to ember-template-lint, you basically end up with a wall of warnings that is never resolved. It demoralizes the developer.
- We're transitioning to a Tailwind oriented approach. This more or less makes Stylelint meaningless in the long run for us.
- Though it did catch some nasty bugs and help with best practices, resolving these issues was non-trivial and largely not worth the effort. "If it ain't broke, don't fix it."
I know that these RFCs ultimately afford the escape valve of simply excluding said packages from one's stack, but I thought I'd add some colour with our experience. All of this is to say I'm sure this tool helps some people, but I'm not sure it's as universal a win as the other linting tools cited.
I recently removed Stylelint from our applications at Precision Nutrition. There was significant push back from our team on this tool. We found that:
- Setting up Stylelint to work with our existing stack was non-trivial. We have a fairly old, and complicated, PostCSS setup that necessitated a fair bit of massaging to appease Stylelint.
- Resolving conflicts was non-trivial for our existing, and large, CSS code base.
- Stylelint's TODO functionality is poor comparative to ember-template-lint, you basically end up with a wall of warnings that is never resolved. It demoralizes the developer.
- We're transitioning to a Tailwind oriented approach. This more or less makes Stylelint meaningless in the long run for us.
- Though it did catch some nasty bugs and help with best practices, resolving these issues was non-trivial and largely not worth the effort. "If it ain't broke, don't fix it."
I know that these RFCs ultimately afford the escape valve of simply excluding said packages from one's stack, but I thought I'd add some colour with our experience. All of this is to say I'm sure this tool helps some people, but I'm not sure it's as universal a win as the other linting tools cited.
These concerns are already addressed in the Drawbacks section: https://github.com/elwayman02/rfcs/blob/stylelint/text/0814-stylelint.md#drawbacks
We discussed this in the cli meeting today and decided to move it to final comment period. We'd like to hear more feedback on this topic, if there is any, but agree that it is broadly inline with other linting we do.
in all of the projects that we work with, this would be almost a no-op due to the use of tailwindcss; I can see this potentially adding a few extra seconds to the runtime of a lint:* command
I wonder if a better approach would be to offer people a way to opt into stylelint via something like ember-apply, as I can be sure we will remove the packages on upgrade, in order to ever so slightly lessen the burden of packages needing to be kept up to date.
on a final note I believe that the proposal should also add the config file .stylelint.js to the .eslintrc.js overrides section where all the other .config files live
@void-mAlex If you remove the scripts in package.json for stylelint (would remove any extra time for the lint command) and the related packages, and use ember-cli-update to upgrade in the future, they shouldn't come back. That said, there does seem to be a maintained plugin for stylelint config. for tailwindcss.
@void-mAlex I think your last concern is covered here.
I did read that but somehow didn't make the connection even searched for eslintrc to double-check I didn't miss it. you are correct though.
@void-mAlex If you remove the scripts in
package.jsonfor stylelint (would remove any extra time for thelintcommand) and the related packages, and useember-cli-updateto upgrade in the future, they shouldn't come back. That said, there does seem to be a maintained plugin for stylelint config. for tailwindcss.
as far as I can tell the only thing it does is disable stylelint rules when you use tailwindcss and its special @ syntax
rules: {
'at-rule-no-unknown': [
true,
{
ignoreAtRules: [
'tailwind',
'apply',
'layer',
/** tailwindcss v1, v2 */
'variants',
'responsive',
'screen',
],
},
],
'function-no-unknown': [
true,
{
ignoreFunctions: ['theme'],
},
],
},
in case you're talking about stylelint-config-tailwindcss which is the one I found so it's not really useful as the point is to have the styles generated based on what you actually use in the template
so app.css has 3 lines in it
can we have a flag to opt out?
If you mean a flag while running the blueprint, I don't think that would be bad and it could be an implementation detail. I don't think the RFC needs to commit one way or the other.
Framework team discussed this today and have decided to merge. The actual merge is pending technicalities (updates to the frontmatter).
@kategengler sorry for the delay! I just got back from vacation and have updated the frontmatter as you suggested.
Framework team discussed this today and have decided to merge. The actual merge is pending technicalities (updates to the frontmatter).
What is the status on this one? Still pending for required changes to frontmatter?
I've opened up an implementation for this RFC in:
- https://github.com/ember-cli/ember-cli/pull/10122
