Fixed Tailwind eslint config path resolution in all apps#26840
Fixed Tailwind eslint config path resolution in all apps#26840
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
WalkthroughESLint configs in apps (admin-x-settings, activitypub, admin-x-design-system, comments-ui, posts, signup-form, stats) now define a local 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Same fix as Shade (#26821) — eslint-plugin-tailwindcss resolves config paths relative to CWD, not relative to .eslintrc.cjs. Using __dirname ensures correct resolution when lint-staged runs from repo root.
acdc2bd to
99745d4
Compare
Same fix as Shade (#26821) and admin-x-settings — eslint-plugin-tailwindcss resolves config paths relative to CWD, not relative to .eslintrc. Using __dirname ensures correct resolution when lint-staged runs from repo root. Affected apps: posts, stats, activitypub, admin-x-design-system, signup-form, comments-ui
Summary
eslint-plugin-tailwindcssconfig path resolution in all apps that use it'tailwind.config.cjs'to absolute${__dirname}/tailwind.config.cjsusing atailwindConfigvariableeslint-plugin-tailwindcssresolves config paths relative to CWD, not relative to.eslintrc.cjs. Whenlint-stagedruns from the repo root, the plugin falls back to Tailwind defaults, producing different class orderings than when running eslint from the package directory.Affected apps:
admin-x-settings,posts,stats,activitypub,admin-x-design-system,signup-form,comments-uiI strongly suspect that this fixes the tailwind classname ordering issue various people have seen when using VSCode's
eslint.fixAll"codeActionOnSave" configuration. The problem fits the same pattern: if you open up VSCode to a particular app directly, there's no issue, but if you open VSCode in the monorepo root, you run into conflicts between the code action's module resolution andyarn lint's module resolution. Explicitly using the absolute path to the tailwind configuration should align the module resolution, regardless of which directory you've opened in VSCode.Test plan
yarn lintfrom any affected app directory — should passnpx eslint apps/<app>/src/ --no-cachefrom repo root — should produce same results as above