FAQ
Do I still need the Stylelint CLI if I use this plugin?β
Not necessarily.
If your goal is a unified lint pipeline, ESLint + stylelint2/stylelint is usually enough.
Keep a dedicated Stylelint CLI job only if you need separate formatter/output contracts.
Which preset should I start with?β
- Start with
stylelintOnlyfor minimal-risk adoption. - Start with
recommendedif you want bridge + config quality enforcement from day one.
Why am I seeing both ESLint and Stylelint errors for similar issues?β
You may have overlapping policy between ESLint ecosystem rules and bridged Stylelint rules. Audit overlap and choose one source of truth for each policy area.
Can I use autofix safely?β
In most repos, yesβstart by running eslint --fix in a branch and reviewing the diff.
Then enforce in CI once results are stable.
How do I lint files that require custom parsers/syntaxes?β
Configure the stylelint rule with customSyntax (and related options) so Stylelint parses those files correctly.
What if some packages in a monorepo resolve config differently?β
Set configBasedir intentionally and avoid fragile relative paths in Stylelint config references.
Use package-install validation rules to catch missing dependencies early.
Why do config authoring rules matter if my Stylelint config already works?β
A config can "work" while still being brittle, duplicated, or hard to review. Authoring rules reduce long-term churn and make diffs deterministic.
Whatβs the best migration order for existing repos?β
- Enable one preset.
- Run autofix.
- Resolve high-value violations first.
- Promote warnings to errors once baseline is clean.
Where should I go next?β
- Setup flow: Getting Started
- Bridge internals and behavior: Stylelint Bridge
- Config quality conventions: Config Authoring