Repository navigation
Support request: Ability to turn off the warnings #3
Description
Activity
Alternatively, does it really need to warn me if I pass a string as a root argument of
e? That would have the same risks of passing any strings directly toclassNamewhen using regular Tailwind. I agree with this warning if I pass a variable into a key'd value, but as a root argument I don't think it should make a difference.Hi! Can you give me some examples?
Instead of trying to guess something, it would be faster to see the example and warning.
Because if there's an warning, its possible things are not being parsed. Before TW JIT it "compiles" but if there's something it can't, then it just don't "compile" anything. Sometimes this means that previous cached values are still valid, but in a clean state things would stop working.
Hey, so here's a simple example!
const Button = (props) => ( <button {...props} className={e( className, "px-4 py-2 uppercase bg-blue-300 text-white transition-all", { hover: "shadow", "focus-visible": "shadow" active: "!shadow-none" } )} /> ); // some place where I'm using Button, I need it to be full width on mobile // I think in this case it's pretty obvious that I need to wrap this input with e // but even if it wasn't obvious, I'd still have to notice that just passing // an object forward didn't work <Button className={e({ mobile: "w-full" })} />
Yes, as I thought... className will be out of scope in the compile, will throw and then only the normal tw jit will run.
I still don't have a good idea on how to deal with that.
Wait, so in that case the
classNameon the last line won't work even though it's wrapped in anecall?It will work, the problem is the call inside the button. That one won't find
classNameand will do just the normal TW that won't understand the object.In my opinion, as long as I'm only sending it a string then that shouldn't be a problem. Seems like it would only be an issue if I passed an object. But I'm assuming that the parser you have access to is unaware of the declared TypeScript types for the variable, right? It just knows that some reference value is being passed in and that it can't deal with that.
Could we possibly have a whitelist (that you can add to your config) that can allow certain variable names or something to not trigger the warning. e.g. I think passing a variable named
classNameforward should be a valid use-case because it's fair to assume thatclassNameis just a forwarded string which would've already either been hit by the Tailwind compiler or I would've constructed that string using a call toeso that string has already been addressed.One thing is runtime (this one accept basically anything as long as it can calculate it).
Another thing is TW JIT compiler, in this step, all it have is code that will not actually run. Before that step, I add a step that computes whats there, but it doesn't really have access to out of scope variables.Today, I know that the best solution would be using AST (abstract syntax tree) parser.
This should make it accept a lot of things and work as long as its not something like{ key: outOfScopeVariable }.I just need to get the time to venture on that.
Reacted by Ethan Standel
I realize that the recommendation for variable classNames is to just pass them in to a string interpolation, but I prefer the cleanliness of passing them into
e. I understand that they risk being outside of the TW JIT, but I'd notice if the styles weren't having an effect at build time. So I'd like to be able to turn off the warning prints.