Fork me on GitHub
#shadow-cljs
<
2022-11-09
>
agorgl09:11:10

Hello! I'm using tailwindcss in a shadow-cljs (re-frame) project. When making release builds (using npm run release ) I notice that various css classes that use the data variants (https://tailwindcss.com/blog/tailwindcss-v3-2#data-attribute-variants) like data-[enabled=true]:bg-red-800 are not included in the generated css file. I suppose it is some kind of obfuscation problem where shadow-cljs obfuscates the class names in the output code and tailwindcss cannot properly detect in the optimized output that they are used? Anybody encountered this?

thheller09:11:34

shadow-cljs never touches or optimizes raw strings, so this shouldn't affect anything

thheller10:11:32

what do you use as the inputs for tailwind jit?

thheller10:11:39

the release output files or the sources?

agorgl10:11:54

Well I for example I can see in the generated css output this: Using rm -rf resources/public/{js,css}; npx shadow-cljs compile app; NODE_ENV="production" TAILWIND_MODE="build" ./node_modules/.bin/tailwindcss -i tailwind.css --config tailwind.config.js -o resources/public/css/site.css

.group[data-edit=false] .group-data-\[edit\=false\]\:hidden {
  display: none;
}

.group[data-edit=true] .group-data-\[edit\=true\]\:hidden {
  display: none;
}
While using rm -rf resources/public/{js,css}; npx shadow-cljs release app; NODE_ENV="production" TAILWIND_MODE="build" ./node_modules/.bin/tailwindcss -i tailwind.css --config tailwind.config.js -o resources/public/css/site.css (with only difference being npx shadow-cljs release instead of compile)
.group[data-edit\x3dfalse] .group-data-\[edit\\x3dfalse\]\:hidden {
  display: none;
}

.group[data-edit\x3dtrue] .group-data-\[edit\\x3dtrue\]\:hidden {
  display: none;
}

thheller10:11:02

hmm where do those \x3d come from?

thheller10:11:22

are they in the JS or does tailwind generate them for some reason?

agorgl10:11:37

@thheller I'm using tailwindcss jit with

"resources/public//**/*.js",
    "resources/public//**/*.html"
as the sources btw

agorgl10:11:30

@thheller I don't know, I made two identical builds with the commands showed above, took the css files from both builds into nvim -d to diff them and saw this

thheller10:11:46

hmm this seems to be the closure compiler

agorgl10:11:59

I tried searching/reading the obfuscated js output but it is damn impossible

thheller10:11:46

ok, the closure compiler does this for safety. escaping everything that may lead to XSS attacks

thheller10:11:10

tailwind just doesn't translate it "back" when generating css

thheller10:11:35

I can add a config flag to disable this, so the closure compiler leaves everything as is

thheller10:11:57

but the default actually makes things safer, so ideally this would be fixed in tailwind?

thheller10:11:10

maybe you can just search and replace \x3d with =?

agorgl10:11:48

I'm using tailwind using this build hook https://github.com/teknql/shadow-cljs-tailwind-jit and I do not track the generated outputs in order to fix them.. I just ended up with the poc above trying to find the problem

agorgl10:11:30

I also see that tailwind generates some classes that include \x3d in the non release builds

agorgl10:11:05

I suppose that a fix in tailwind would be the correct solution, I just don't know how to express it

agorgl10:11:06

Also I'm starting to doubt if I should use sources or the generated clojurescript output as inputs

thheller10:11:31

well I absolutely do not recommend the hook approach this lib uses

thheller10:11:45

but that is irrelevant to this particular problem

thheller10:11:57

and I recommend running over the output not the sources

agorgl10:11:33

I do run tailwind over the output, mind explaining the reason? I suppose for the pruned/optimized outputs?

thheller10:11:29

well, :advanced may have removed some tailwind string that you didn't use but still have in the sources

thheller10:11:41

if you run over the sources they'll end up in your css

thheller10:11:48

if you run over the output they'll be gone completely

agorgl10:11:28

Yeah makes sense

agorgl10:11:11

Could you mind explaining how the = \x3d replacement works in clojurescript compiler in order to report it upstream in tailwindcss?

thheller10:11:27

it has a "trusted strings" option, which defaults to false. ie. it doesn't trust strings in the source, and to be safe escapes certain characters (eg. <>=) with \x3d etc

thheller10:11:58

I'm not entirely sure how you'd attack such a thing with your own sources, but I guess its there for good reason

thheller10:11:42

I just added the option to disable this, if you want I can make a release for that

thheller10:11:24

I generally do not like turn off safety things by default, so this is opt-in but would fix your problem probably

agorgl10:11:49

Yes, thank you this would be awesome!

thheller10:11:02

2.20.8 and :compiler-options {:trusted-strings true} in your build config

agorgl10:11:14

It works, thank you

👍 1
agorgl10:11:37

It is probably one of the fastest upstream releases I've ever seen

thheller10:11:21

I'm sitting here waiting for a delivery. so basically idle anyways 😛

agorgl10:11:01

Should we report this to tailwind?

thheller10:11:46

"we" won't, but you can 😉 too busy to follow this through on the tailwind side myself. also don't use tailwind anymore 😉

agorgl11:11:30

Anything to add?

thheller11:11:24

well you could make a repro with just a dummy script and showing what the output is

thheller11:11:56

and then just that the closure compiler generates such sources, doesn't really need to be involved in the repro