This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # beginners (103)
- # boot (6)
- # cider (10)
- # cljs-dev (57)
- # cljsrn (60)
- # clojure (132)
- # clojure-dusseldorf (2)
- # clojure-germany (1)
- # clojure-italy (6)
- # clojure-russia (18)
- # clojure-spec (1)
- # clojure-uk (58)
- # clojurescript (61)
- # core-async (1)
- # cursive (17)
- # datascript (1)
- # datomic (17)
- # docs (1)
- # duct (5)
- # editors (1)
- # emacs (7)
- # events (1)
- # figwheel (7)
- # fulcro (37)
- # graphql (8)
- # jobs (3)
- # leiningen (23)
- # luminus (14)
- # mount (6)
- # off-topic (43)
- # onyx (14)
- # protorepl (2)
- # re-frame (7)
- # reagent (32)
- # shadow-cljs (234)
- # tools-deps (88)
- # unrepl (8)
- # vim (60)
- # yada (1)
lots of stuff in
node_modules can’t pass through Google Closure advanced optimizations
is what you’re describing really something that Node.js users do - definitely wasn’t my impression
That's fair. It should still be possible to bundle them into a single file without doing advanced optimizations though, right?
I just don't like the idea of shipping
node_modules with a ton of unused dependencies.
Yeah, it's definitely a niche use case. I'm experimenting with running webpack on the output, and it seems to be working fine so far.
@jumblemuddle I would guess that there are tools in the npm world that do this? should be usable with CLJS once you have an optimized build?
@thheller That's what I'm looking into now. I was hoping to avoid dipping into that world. I'm looking into webpack or browserify now.
I think they'll do what I want. (Analyze the optimized build for
require() statements and pull from
node_modules into a bundle.)
I thought that was more about shipping a binary that didn't require node. I don't mind shipping a shebang node script. I just don't want
node_modules to have to be shipped with it.
Well, in this case I'm sending a single
bundle.js file to AWS Lambda. Though I'm also thinking of the usecase of scripts to be run from the command line.
@jumblemuddle can you keep me posted, was trying to do the same some time ago
I'm not sure about that. I could certainly ship the whole
node_modules folder if I wanted.
I want to have everything centralized in
:npm-deps and let cljs handle it.
if we had a clj solution that for sure would be better. Lumo already has a lot of util functions that scan
@dnolen I can't think of anything critical. Out of all of the various Windows fixes, all of them were defects in the testing code apart from https://dev.clojure.org/jira/browse/CLJS-2721 which you applied.
@mfikes ok I have 3 things in critical for next release, but maybe I will only handle the spec fn arity limit one
the two others will probably end up being part of bigger push to clean up how modules are handled
this might be a bit tricky so that’s why it might be the only other thing I do for next release
:white_check_mark: Windows CI is green again https://ci.appveyor.com/project/mfikes/clojurescript/history And it is actually checking its test results for success / fail.
You mentioned interest in the websocket stuff for next release. I haven't had a chance to work on it since last we spoke but I'll be hacking on it this weekend. Not sure if I'll have things ready by next release but if you want a WIP patch submitted just let me know.
browserify --node --standalone index index.js | uglifyjs -o bundle.js works great. It pulls the needed dependencies from
node_modules and bundles them into a single output file.
Yeah, sorry, I could've made that more clear. I output with
:optimizations :advanced, then I run it through browserify and uglify.
Right, so it is for a script I don't need advanced for now...it basically here and https://github.com/paullucas/les-clj/blob/master/scripts/build
Probably I am missing the she-bang node and at the moment the script is not working
I briefely looked into rollup, but I didn't get very far. Let me know how it goes if you try it.