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:
"@typescript-eslint/no-empty-interface": [
"error",
{
allowSingleExtends: true,
},
],
"@typescript-eslint/no-empty-interface": [
"error",
{
allowSingleExtends: true,
},
],
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
couincouin007
couincouin007•11mo ago
anyone? 🙂
JoshuaKGoldberg
JoshuaKGoldberg•11mo ago
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.
JoshuaKGoldberg
JoshuaKGoldberg•11mo ago
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.
couincouin007
couincouin007•11mo ago
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 🙂
Want results from more Discord servers?
Add your server