This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # architecture (4)
- # aws (1)
- # beginners (63)
- # cider (26)
- # clara (9)
- # cljs-dev (42)
- # cljsrn (1)
- # clojars (8)
- # clojure (43)
- # clojure-finland (3)
- # clojure-italy (3)
- # clojure-nl (3)
- # clojure-poland (9)
- # clojure-spec (1)
- # clojure-uk (81)
- # clojurescript (38)
- # core-async (1)
- # cursive (33)
- # datomic (29)
- # duct (12)
- # editors (4)
- # emacs (2)
- # fulcro (25)
- # jobs (3)
- # leiningen (2)
- # off-topic (20)
- # onyx (1)
- # portkey (20)
- # proton (2)
- # re-frame (38)
- # reagent (36)
- # remote-jobs (1)
- # ring-swagger (1)
- # rum (2)
- # shadow-cljs (167)
- # slack-help (1)
- # spacemacs (1)
- # test-check (20)
How difficult would it be to allow
:target :nodejs projects to have their node modules
:optimizations :advanced compiled instead of direct
Briefly attempting to modify the compiler, it seems like the only hurdle it when built-in node functions are required.
Perhaps there's an easy way to do this?
Funny, I was considering something like that myself, are you running on lamdba? Because that is the only use case I had to shrink the dependencies...it would be great to know yours :)
Yeah, I'm using AWS lambda; how'd you guess? :stuck_out_tongue:
I'd like to have a single set of
:npm-deps without having to use the whole
node_modules directory for every lambda that doesn't necessarily use all the
Ah ah I was thinking exactly the same, then David basically convinced me that it is not worth the trouble.
Sorry for the delay. Not worth the trouble in what way? Not worth the trouble to implement it?
he basically was suggesting that the performance you can squeeze out of that is minimal, I would suggest to ask him directly
@ I think there's more to be gained from just performance. Being able to compile everything to a single bundle with a shebang (avoiding
node_modules altogether) for node scripts could be very useful.
I'm experimenting with doing this with webpack at the moment. Is this a good idea?
@thheller so here's a basic example of the lazy dep module stuff I was talking about: https://github.com/johnmn3/cljs-main-code-splitting/blob/master/modules/mod_init/main.cljs
still no idea what your vision is sorry. I stand by saying that using
cljs.loader in a library is not a good idea.
I guess the idea is that modularity should be inheritable by downstream module authors... Sort of like a plugin system.
yeah but you don't know how your client is going to use your code. your
:modules config might not make sense for them.
also in your macro solution
(one/hi-one "mod-acme") makes it appear like this is an actual sync method that you could use say in
(let [x (one/hi-one "mod-acme")] ...) when it actually is an async method doing all kind of stuff.
Right, it's inherently async on that first call... Prefetching on ns load is another option
But if that first call happens on ns load, it'll still be async. Well, you could shelve all calls the the module fns during load time, like is sometimes done in JS - that way it'd feel more like normal - and subsequent calls would resolve to the locally loaded var directly.
and wrt "yeah but you don't know how your client is going to use your code", it may be that this aspect of hot module loading is only feasible in CLJS land, or Closure JS tools that are careful with usage. And, outside of that, it is only useful when defining deployable artifacts to apps.
I can tell you that at least for the app I'm currently working on - which is a sort of combination between MDC and Google Analytics - this workflow would make development for me much easier - in a mono-repo, decoupled way
apps decide if they want to split or not. split usually occurs at the namespace/import level (but Closure can go deeper). so the best you can do is provide reasonable NS setups so apps can pick what they need.
but ultimately the lib should make no presumption whether a split is used or not. (IMHO)
well, it my current setup, if you want to use the thing lazily, you go through the loader route by requiring the
lazy ns. If you want to use non-code-motion, single-DCE-artifact method, you just require the
main ns and call the fn directly through there.
downstream authors then have the option of consuming my lib via individual modules and then defining their own modules that further downstream users can consume, or they can just consume them directly via their
So, I think I'm not presuming how downstream authors want to consume or provide my modules.
cljs.loader is pretty heavily bound to the build config it is. the app must define the exact module name with the exact namespaces and so on.
Folks wanting to construct a new module will need to define their module layout locally to be fully in tune with upstream module layouts, I believe.
yep. doesn't sound very user friendly. I think using
cljs.loader directly is probably easier than using your
all these same limitations exist for MDC though, I think. Constructing new components requires a certain degree of integration with their module framework. Feasibly, though, users could make their own MDC components and use them privately, with all the same benefits that Google is getting out of modularized MDC.
Basically, it's like a library extension mechanism, with the purpose of letting downstream app builders define the final module layout.
MDC modules are not what
:modules is about. JS/MDC modules are basically namespaces for JS
okay, after rereading: https://material.io/components/web/docs/closure-compiler/ I see they don't mention any code splitting...