Conflict between shadcn/ui components and @typescript-eslint/no-empty-interface
I have linting errors while using shadcn/ui components because there are some empty interfaces defined extending other supertype interfaces, as :
interface CommandDialogProps extends DialogProps {}
The @typescript-eslint/no-empty-interface rule prevent the build saying it's an error. I've found that I can configure my eslint rules to satisfy it with:
Did you solve this error with another solution? Even if I understand the value of this rule, I think I'm not alone to use shadcn/ui and with the ESLint T3 stack config, this error is boring...
On the same subject, the @typescript-eslint/consistent-type-imports rule displays warnings also with shadcn/ui components...4 Replies
anyone? 🙂
Hey @couincouin007 sorry for the delay, didn't see this till now - what you did is a good and reasonable solution. Lint rules are just tools you can configure for your needs. The out-of-the-box config is a starter template you can adjust to your needs.
In the case of
interface MyProps extends SomeBaseProps {}, a couple of alternatives you might like are:
* Using SomeBaseProps directly
* type MyProps = SomeBaseProps
* Disabling the @typescript-eslint/no-empty-interface rule altogether
...but it's really up to however you want to work in your project.As for
@typescript-eslint/consistent-type-imports, https://typescript-eslint.io/blog/consistent-type-imports-and-exports-why-and-how has more context on that. If you don't personally care about keeping consistent import styles and your project doesn't have a technical reason to care, then you can always disable the rule. Or just let it auto-fix to be consistent. Either way - totally up to you. There's no single "best practice" beyond being consistent within your project.Consistent Type Imports and Exports: Why and How | typescript-eslint
Why enforcing TypeScript imports use the
type modifier when possible benefits some project setups.thank you @JoshuaKGoldberg for your detailed answer! i understand now better i need to decide for myself how I want to handle it. kinda annoying to have to fix these warnings / errors each time i will use shadcn components, but I understand it's not easy to all have same rules. and i personnaly don't want to see any warnings / errors in my codebase, so i will fix the each time 🙂