I think you can configure the amount of memory the JVM will use

there’s a known issue where docker containers do not expose the amount of RAM actually available, so the jvm will consume more than allocated for the container

you should be able to manually configure the amount of memory the JVM will consume, either through shadow-cljs or through defaults of whatever java runtime you’re using in the container itself

is there a way to rename the default export when requiring a JS library? Looking at the "ES6 Import to CLJS Require" table in the User's Guide, but don't see that, so I was wondering whether I'm missing something obvious?

@thheller I’m getting an error when i open the output from build-report. It was a complaint about an odd number of map elements in a map, because node_modules/date-fns has 201 elements. I suspect this is because the date-fns library contains several sub-folders—one for each function—so that the user can cherry-pick the individual fns she wants to use.

@lilactown @richiardiandrea thanks, it was actually working for me as well. I was just tricking myself by running a separate watcher for the test target and looking there for test results. But the results where coming from my node-libarary target… Now I am running both targets from the same watcher and it works. Almost. I do get en error on startup:

Error: ENOENT: no such file or directory, open '/Users/pez/Projects/calva-fmt/.shadow-cljs/builds/test/dev/out/cljs-runtime/goog.debug.error.js'

(From there on whenever I save the file tests are run. But I would prefer they ran at startup too, w/o throwing errors in my face.)

@lwhorton SIGKILL looks indeed like the process is getting killed by maybe the OOM killer. you can configure the max memory by setting :jvm-opts ["-Xmx2G"] in shadow-cljs.edn.

@samuel.wagen you can choose whatever name you want for :default (eg. :default whatever). the name is completely up to you.

@thheller Oh now I see! it makes sense. thanks.

@pez there was a race condition in :node-test. fixed in master, will make a release later

@levitanong what is the error exactly?

I'm looking to run some node scripts to manipulate some files. Is Nashorn the best way to go about this?

no. node?

It's kind of during the clj-run step.

I want to run Critical to inlines critical css and Subfont to do font subsetting.

still node

you can use clojure.java.shell/sh

Ok I had a feeling that was the case which is why I asked before I dove in.

Ahh yea I was about to ask whats the best way to trigger node scripts. But that seems way more simpler. Just jump into the shell.

shadow-cljs uses babel internally for some of the node_modules rewriting and does so by launching a node process

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/babel.clj#L36

the node process just wait for input from stdin and writes replies to stdout

it basically just communicates via EDN messages back and forth

doesn't have to be this complicated if you just want to call something once

but in case of the babel stuff starting a new node process for each transformed file was way too slow

I want to run Critical, Subfont during the production step. Lighthouse during an Audit step and Puppeteer for a testing step.

My preference would be to stay out of vanilla JS as much as possible. Just thinking through the best way to do it 🙂

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/npm/transform.cljs

this is the file doing the node side of things

you can easily do the same and just communicate via EDN messages

Cheers!

That's what I want to do so that should help me get there

yeah there it is right at the bottom

4360, ...}

no idea how the ... gets there. its supposed to be using the safeguard for that so emacs settings *print-length* doesn't mess it up

oh nvm ...

i used vim for this

i generally use vim for huge files haha

but you are using emacs cider REPL to run the generate

ah right

and thats the problem since emacs unconditionally sets *print-length* for the REPL

it will work if you do (binding [*print-length* nil] (generate ...))

will add a fix for it

hurrah!

thanks @thheller

Yeah, that fixes it!

cider setting *print-length* is really really bad for shadow-cljs 😛

I have a project that builds in shadow 2.4.8 but fails in >= 2.4.9 with > The required JS dependency "entities/lib/decode_codepoint.js" is not available, it was required by "node_modules/htmlparser2/lib/Tokenizer.js". It looks as though the way package require handling changed in 2.4.9: https://github.com/thheller/shadow-cljs/compare/3a43f6d...a2c870c . But require in htmlparser2 looks okay to me... https://github.com/fb55/htmlparser2/blob/master/lib/Tokenizer.js#L3 (unlike the issue with clipboard I ran into last week, the required file does actually exist this time!)

@henrygarner odd. I'll take a look shortly

@henrygarner fixed in 2.4.11. thanks for the report.

Amazing! Thanks @thheller 👌

@smnplk ideally you want to avoid running code "globally" and instead move it into a :dev/after-load callback

since an exception while loading code prevents other code from being loaded properly

I have it in :builds :app :devtools :after-load --> app.main-view

I am using the latest version of cli and npm shadow-cljs

ah right sorry. forgot that any error will cause the display above

The problem occurs only if i call (app-routes) inside main-view function.

but if i add it somewhere outside, all works fine

(app-routes) probably uses goog.History which must only ever be created once

I am importing goog.History

the error means that the div#wrapper element does not exist

Ill try defonce

and goog.History will reset the dom when it is constructed when the page finished loading

whoa, didn't know that it resets the dom.

goog.History is sort of ancient and should probably not be used anymore

https://google.github.io/closure-library/api/goog.history.Html5History.html is the successor

suggestion for any better routing lib that uses Html5History ?

Oh, just found one. Bide 🙂

@thheller, I just switched to Html5History and the problem went away.

for grins i tried running shadow-cljs on an amazon c5d-xlarge instance. i am surprised that it only runs twice as fast as my 2012 era macbook. i guess single threaded performance just isn’t improving much now

on my desktop I get cljs.core compile times of about 2.5sec which is substantially faster than my macbook with about 6sec

yea my macbook is about 6-6.5 seconds

i have the i7-8700k which still seems to be the best in single core perf

wonder how much compiler can still be tweaked to get more out of each core

i feel like there are opportunities for more sophisticated dependency analysis

not for single-ns compiles

can't do those in parallel

big ns like cljs.core are the bottleneck since everything else has to wait for them to compile

i meant more like realizing that although a dependency i include changed, i really don’t need to recompile because the function i’m using didn’t change

i have tons of functions in one file that everything depends on, but in reality each file only depends on a small part. i could break it up (and eventually I will)

yes incremental compiles could definitely be better with some more logic

but I mean clean non-cached performance which I think can be at least 50% faster still

oh interesting. through parallel compile or something?

no just by tweaking things. clojure compiles way faster but has to do a lot more work since the JVM is much less dynamic than JS

so there are still probably some bottlenecks in the code somewhere that just need to be found and fixed

its not a fair comparison since most of the clojure compiler stuff is written directly in java

I was wondering if crowdfunding a slack pro for clojurians would be worth it?

op, just looked at pricing lol

it would be insanely expensive

Yeah, I thought I saw reasonable pricing a while back, but for that price it's not even worth the history

And I clicked the wrong forum, my bad