This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-09
Channels
- # aleph (1)
- # announcements (7)
- # asami (1)
- # beginners (44)
- # calva (54)
- # cherry (24)
- # cider (6)
- # clj-kondo (19)
- # cljsrn (27)
- # clojure (119)
- # clojure-europe (61)
- # clojure-gamedev (38)
- # clojure-germany (7)
- # clojure-nl (1)
- # clojure-norway (104)
- # clojure-portugal (4)
- # clojure-spec (4)
- # clojure-uk (1)
- # clojurescript (38)
- # cursive (18)
- # datomic (11)
- # emacs (9)
- # events (1)
- # fulcro (4)
- # holy-lambda (7)
- # introduce-yourself (7)
- # jobs (1)
- # malli (6)
- # off-topic (4)
- # pathom (4)
- # pedestal (16)
- # podcasts-discuss (1)
- # polylith (27)
- # portal (17)
- # releases (2)
- # shadow-cljs (46)
- # squint (1)
- # xtdb (9)
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?
shadow-cljs never touches or optimizes raw strings, so this shouldn't affect anything
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;
}
@thheller I'm using tailwindcss jit with
"resources/public//**/*.js",
"resources/public//**/*.html"
as the sources btw@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
ok, the closure compiler does this for safety. escaping everything that may lead to XSS attacks
I can add a config flag to disable this, so the closure compiler leaves everything as is
but the default actually makes things safer, so ideally this would be fixed in tailwind?
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
I also see that tailwind generates some classes that include \x3d in the non release builds
I suppose that a fix in tailwind would be the correct solution, I just don't know how to express it
Also I'm starting to doubt if I should use sources or the generated clojurescript output as inputs
I do run tailwind over the output, mind explaining the reason? I suppose for the pruned/optimized outputs?
well, :advanced
may have removed some tailwind string that you didn't use but still have in the sources
Could you mind explaining how the = \x3d replacement works in clojurescript compiler in order to report it upstream in tailwindcss?
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
I'm not entirely sure how you'd attack such a thing with your own sources, but I guess its there for good reason
https://github.com/thheller/shadow-cljs/commit/5cf0ea00a08e4de75d30465a9d84b8ad6846e2f8
I generally do not like turn off safety things by default, so this is opt-in but would fix your problem probably