This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-17
Channels
- # announcements (17)
- # aws (2)
- # babashka (21)
- # beginners (67)
- # calva (19)
- # cider (29)
- # clara (3)
- # clj-kondo (6)
- # cljsrn (10)
- # clojure (140)
- # clojure-europe (164)
- # clojure-nl (3)
- # clojure-uk (8)
- # clojurescript (62)
- # conjure (7)
- # core-async (24)
- # cursive (21)
- # datomic (5)
- # docker (40)
- # emacs (14)
- # fulcro (25)
- # gratitude (1)
- # honeysql (6)
- # introduce-yourself (1)
- # jobs (1)
- # jobs-discuss (32)
- # juxt (7)
- # lsp (13)
- # minecraft (2)
- # off-topic (49)
- # pathom (24)
- # practicalli (8)
- # re-frame (18)
- # react (23)
- # remote-jobs (6)
- # reveal (2)
- # shadow-cljs (75)
- # tools-deps (7)
Hello! Just to be sure before doing some tests, I would to know if I go in the right direction.
This is about :js-provider :external
js-options.
I can use the external-index
file to do some tree shaking with for eg. webpack, right?
or rather I don't know what webpack tree shaking looks like these days. I doubt it though.
OK, so this is maybe not the solution for one project.
what kind of shaking are you looking for? generally the best result you'll get is by using modular libs that allow you to access certain stuff directly
whether you use those with just shadow-cljs or together with webpack will then be a minor difference
After checking the file, I understand that bundler cannot works on DCE because the require
are "global" in compare in my CLJS code.
ALL["@ant-design/icons"] = require("@ant-design/icons");
ALL["@ant-design/pro-layout"] = require("@ant-design/pro-layout");
ALL["react-dom"] = require("react-dom");
["antd/es/button" :default Button]
["@ant-design/pro-layout" :default ProLayout :refer [PageContainer]]
["@ant-design/icons" :refer [AppstoreOutlined FileTextOutlined LikeOutlined SettingOutlined AlipayCircleFilled]]
good example. instead of requiring the @ant-design/icons
directly which itself imports thousands of other things you are unlikely to use
just require what you actually use directly, eg. (:require ["@ant-design/icons/FileTextOutlined" :as FileTextOutlined])
Yes thank you. This is my first try but I go in direction to :js-provider :external
because Ant design lib relies heavily on importing less css file for all his components
node_modules/antd/es/tag/style/index.js:import '../../style/index.less';
node_modules/antd/es/tag/style/index.js:import './index.less';
node_modules/antd/es/time-picker/style/index.js:import '../../style/index.less';
node_modules/antd/es/time-picker/style/index.js:import './index.less'; // style dependencies
So it breaks Shadow-cljs build.
I knwo I can avoid this error excluding assets with ignore-asset-requires true
but after that the CSS styles are missing for these components.
So I try to find the best way to glue all of that.
not a clue. antd has always been rather terrible from a package perspective. requiring custom webpack plugins and so on to work
Perfect, make sense. Thank you for the confirmation.
So if I want to use Shadow-CLJS + Webpack, :js-provider :external
is the only solution, right?
For my project right now it works well, except my external-index
file size is 1.8M 😕
This is the reason for my first question.
OK, I try that right now, thanks.
Maybe this approach would be interesting in the CLJS world: https://github.com/ant-design/babel-plugin-import#example
Don't know if it's doable
why complicate your build setup 10x when you can just require the icon you want and write 3 lines more code?
For my part, it suits me very well to target imports. It was more of a suggestion / idea in order to avoid mistakes when working as a team.
In fact, it remains only good practices to be communicated at the team. 👍
Thank you for your precious help.
antd is one of those libs that really really wants you to use webpack so definitely go with that
I had some code to make the external-index generate actual import { Thing } from "thing"
instead of require
but that had all sorts of other issues
Interesting. What kind of issues ? Specific for some config or globally very unstable ?
commonjs <-> ESM interop issues mostly. say you have reagent using (:require ["react" :as react])
that would map to import * as react from "react"
but given that react is shipped as commonjs only it must be imported via import react from "react"
but figuring this out at build time is hard when not actually building JS (since webpack will do it)
so either it would requiring some sort of config you'd need to provide manually or some magic I don't like
can't have reagent change the import since that would then break others not using ESM
OK I understand. Being able to configure that would be great! Thank you for all these details.
Your code to make external-index generate import is on testing branch?
Perfect, I'll check.
Hi, I come back to our exchange because I continued my tests and I am a little desperate and I will seek confirmation before abandoning the plan to use Ant design pro with ClojureScript.
Even targeting components, icons directly, my external-index
bundled by webpack weight more than 1,1Mb.
["@ant-design/pro-layout" :default ProLayout :refer [PageContainer]]
["@ant-design/icons/AppstoreOutlined" :default AppstoreOutlined]
["@ant-design/icons/FileTextOutlined" :default FileTextOutlined]
["@ant-design/icons/LikeOutlined" :default LikeOutlined]
["@ant-design/icons/SettingOutlined" :default SettingOutlined]
["@ant-design/icons/AlipayCircleFilled" :default AlipayCircleFilled]
As the external-index
file uses commonjs require then I can't do anything at webpack level, like eg tree shaking like with es import, right?
Here is how Ant design pro exports its components: https://github.com/ant-design/pro-components/blob/master/packages/layout/src/index.tsx#L29-L59
@thheller This is not a personal project but a professional request and your opinion will be very valuable in order to know if I can confirm that there is a solution or if I must give up. Thanks
Hello, if I have a namespace that looks like this
(ns foo.bar)
(def dog "doug")
and another namespace
(ns foo.bar.dog)
;; other stuff
I end up with a namespace clash
Namespace foo.bar.dog clashes with var foo.bar/dog
That makes sense, I understand why that happens.
Is there a way to work around this without renaming namespaces or vars? I was thinking there would be some configuration for my :target :browser
build where I could declare something the effect of
"namespace foo.bar should be compiled to the name 'something_completely_different' on the output javascript object"
It's not that big of a deal, I can always rename, but it would be nice to be able to keep the ones I have right now.@dannyfreeman that would need to be solved in the cljs compiler directly. not something shadow-cljs can change.
Got it, thanks for the quick response. We'll just re-think our names, no big deal.
yeah its unfortunate. I'd like to change it myself but that may break a lot of code out there
Everything has it's quirks, cljs is no different
Does the :browser target support the :exports option? I'm trying to build a browser package and a node package from the same source, but I'd like to exclude some node-specific functions from the browser build.
I am setting it up as a separate build already, just they both use the same source. I guess I can move the node-specific stuff to another namespace and include it as a submodule