Fork me on GitHub
#cljs-dev
<
2018-04-13
>
dnolen20:04:14

anything critical I should be looking at for the next release?

dnolen20:04:03

you don’t need :advanced for that

dnolen20:04:11

:simple & :whitespace also generate a single file

Garrett Hopper20:04:37

Not for :target :nodejs they don't.

dnolen20:04:53

hrm, that’s news to me

Garrett Hopper20:04:01

However it still needs to be shipped with node_modules.

dnolen20:04:30

I think you are confused though

dnolen20:04:54

lots of stuff in node_modules can’t pass through Google Closure advanced optimizations

dnolen20:04:02

probably doubly true for stuff that isn’t intended for the browser

dnolen20:04:33

is what you’re describing really something that Node.js users do - definitely wasn’t my impression

Garrett Hopper20:04:41

That's fair. It should still be possible to bundle them into a single file without doing advanced optimizations though, right?

Garrett Hopper20:04:19

Eh, it might not be. My particular usecase is a little strange.

dnolen20:04:31

hrm I don’t know

dnolen20:04:45

we have to weigh the value of making something like this work

Garrett Hopper20:04:48

I just don't like the idea of shipping node_modules with a ton of unused dependencies.

dnolen20:04:52

sounds like a lot of trouble for very little gain

Garrett Hopper20:04:37

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.

thheller20:04:17

@ghopper 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?

Garrett Hopper20:04:02

@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.

Garrett Hopper20:04:46

I think they'll do what I want. (Analyze the optimized build for require() statements and pull from node_modules into a bundle.)

Garrett Hopper20:04:27

This should avoid shipping excessive node_modules with each separate build.

Garrett Hopper20:04:56

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.

thheller20:04:24

how do you plan to do the "shipping"?

Garrett Hopper20:04:28

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.

thheller20:04:24

doesn't AWS support installing deps from package.json?

richiardiandrea20:04:49

@ghopper can you keep me posted, was trying to do the same some time ago

richiardiandrea20:04:13

scripts is also the use case I am looking at now

Garrett Hopper20:04:16

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.

richiardiandrea20:04:40

if we had a clj solution that for sure would be better. Lumo already has a lot of util functions that scan node_modules.

richiardiandrea20:04:48

actually JVM as well

mfikes20:04:28

@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.

dnolen21:04:27

@mfikes ok I have 3 things in critical for next release, but maybe I will only handle the spec fn arity limit one

dnolen21:04:57

the two others will probably end up being part of bigger push to clean up how modules are handled

mfikes21:04:04

Oh, are spec instrument arity fns coming back to haunt us? Ugh.

dnolen21:04:17

well not quite

dnolen21:04:26

they give a real reason to handle the 20+ argument case 🙂

dnolen21:04:34

this might be a bit tricky so that’s why it might be the only other thing I do for next release

mfikes21:04:41

(Just guesing... I haven't looked into that stuff.)

dnolen21:04:47

yes related

mfikes21:04:44

Windows CI is green again https://ci.appveyor.com/project/mfikes/clojurescript/history And it is actually checking its test results for success / fail.

🎉 8
john21:04:17

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.

dnolen21:04:43

yes feel free to submit WIP patch

Garrett Hopper22:04:43

@richiardiandrea 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.

richiardiandrea22:04:03

so I assume your cljs compiler output is index.js ?

Garrett Hopper02:04:03

Yeah, sorry, I could've made that more clear. I output with :optimizations :advanced, then I run it through browserify and uglify.

richiardiandrea02:04:39

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

richiardiandrea02:04:01

Probably I am missing the she-bang node and at the moment the script is not working

richiardiandrea02:04:55

Seems like an easy fix so thanks a lot!

richiardiandrea03:04:22

I wonder if I could achieve the same thing with rollup

Garrett Hopper15:04:48

I briefely looked into rollup, but I didn't get very far. Let me know how it goes if you try it.

richiardiandrea15:04:03

It seems it supports es6 only, don't want to go down the rabbit hole for now

richiardiandrea23:04:54

I got a weird error today:

Caused by: clojure.lang.ExceptionInfo: No such namespace: fs, could not locate fs.cljs, fs.cljc, or JavaScript source providing "fs" in file /home/arichiardi/git/les-clj/src/les/core.cljc {:tag :cljs/analysis-error}