Open kachkaev opened 1 year ago
I have managed to patch eslint-plugin-tailwindcss
in https://github.com/kachkaev/eslint-plugin-tailwindcss-issue-267-mwe/pull/1. It seems to be doing what I expect it to. Can this be converted into a PR or am I missing a use case that can throw a spanner in the works?
I guess we can try hardcoding cva
just as it currently done for classnames
. If that causes issues (which I doubt because cva
is quite unique), we can create an new settings option.
I encountered the same issue, and I can confirm that @kachkaev's patch resolves it. It would be great if this fix could be incorporated!
Iβve stopped using this patch myself. Turns out that object syntax inside cn
is not that useful and can be omitted:
cn("text-white bg-black", {
"p-4": condition,
"p-oops": anotherCondition, // π¨ no ESLint error here
});
β
cn(
"text-white bg-black",
condition && "p-4",
anotherCondition && "p-oops", // π ESLint error here: `Classname 'p-oops' is not a Tailwind CSS class! tailwindcss/no-custom-classname`
);
My cn
function:
/**
* Same as `ClassNameValue` from `tailwind-merge`, but without support for arrays
* (to keep arguments simple)
*/
export type ClassNameValue = string | null | undefined | 0 | false;
/**
* @example `cn('foo', condition && 'bar', condition && 'baz')`
*/
export function cn(...inputs: ClassNameValue[]): string {
return twMerge(inputs);
}
This function used clsx
, this dependency can be uninstalled.
Because objects inside cva
are supported by eslint-plugin-tailwindcss
anyway, all class names in my projects are covered even without a patch. Here is what I have in .eslintrc.js
:
settings: {
tailwindcss: {
callees: ['cn', 'cva'],
ignoredKeys: ['defaultVariants'],
config: `${__dirname}/tailwind.config.ts`,
},
},
This issue is still valid, but one can bypass it by stepping a bit to the side.
@francoismassart would you be able to add @kachkaev's patch above to this repo? Would be great to have.
I am giving a little bump to this as my team has a huge codebase that uses keys as class names and we ran into this issue, @kachkaev patch would be great to have
@zegs21 consider dropping object arguments completely, as described in https://github.com/francoismassart/eslint-plugin-tailwindcss/issues/267#issuecomment-1907798102. Iβm quite happy with just &&
s for conditional styles after a few months of banning { "class": condition }
syntax. There is now only one way of doing one thing instead of two, which reduces cognitive load and PR discussions π The initial migration from {}
to &&
was quite smooth too (and our teamβs codebase is not small).
Describe the bug
There are several common
callees
which support objects with class names in keys. The existing implementation of a few rules only scans object keys in a function namedclassnames
. This results in false negatives when a rule liketailwindcss/no-custom-classname
is enabled.https://github.com/francoismassart/eslint-plugin-tailwindcss/blob/6b6c0dd28e123cc118bff83654f951f736fa58e8/lib/rules/no-arbitrary-value.js#L109-L116
To Reproduce
Expected behavior
Iβd expect all my callees except
cva
to work just aclassnames
function. It seems more reasonable than to putcva
in the deny-list rather thanclassnames
into the allow list for keys.Screenshots
Environment (please complete the following information):
"eslint-plugin-tailwindcss": "3.13.0"
Additional context
Support for object keys was requested in #99 and got implemented in #103. Then #135 was raised, requesting support for
cva
(which produced false positives at the time). This issue withcva
was resolved in #185. When doing so, support for allclassname
function aliases got dropped.If the sole goal of #185 was to support
cva
, we can probably avoid a new config option likecalleesWithClassNamesInObjectKeys
. π¬ Maybe this fix would do?In the meantime, I will probably change the signature of my custom
cn
function (clsx
+tailwind-merge
) like this:eslint config file or live demo
MWE repo: kachkaev/eslint-plugin-tailwindcss-issue-267-mwe