Funny thing, Rust's tool for building into WASM also has target bundler https://rustwasm.github.io/docs/wasm-bindgen/reference/deployment.html#bundlers

> Currently the only known bundler known to be fully compatible with wasm-bindgen is webpack.

might as well call it target webpack 😛

@dominicm sorry mies is no longer the bar - using ClojureScript directly - it used to be that wasn't that practical but with cljs.cli not really true anymore. Are you calling cljs.closure/build ? If so not really recommended anymore cljs.build.api/build

@dnolen np, bit more involved to get that set up. I'm using cljs.build.api/build

re: the thing you're talking about is known, a historical ugliness

and a refusal to break the old way - pretty sure if you can pass nil for 1st arg if you don't care

re: optimizing :bundle-cmd I don't really like that idea so much, but mostly because I think the class of things you might want to customize is larger than this particularly issue. Also any optimization here is bound to be a bit ugly. :bundle-cmd can be arbitrary

so why not a command that first checks if npm_deps.js is equal to npm_deps.last.js runs webpack if they're different, copies npm_deps.js to npm_deps.last.js

the first time you build it won't exist

@darwin that Blender / CLJS approach seems like a lot of effort - I don't see the advantage over Client/REPL strategy - with the later you can definitely have something working in a couple of weeks - and something great in a couple of months since you just reuse everything already in ClojureScript

since you're embedding anyway you have a lot of control you don't have in say React Native wrt. sync file loading for dev etc.

@roman01la I think the important thing here if alternative targets are going to succeed is to stop thinking about it as a giant project. In fact best to start with a toy - ClojureScript was a toy too at one point.

I would make a project that just attempts to generate Dart from ClojureScript - it doesn't need to do everything

unconcerned with anything except generating some simple source from s-exprs

and everytime you hit a small hitch that's a discussion / JIRA ticket

if this is done as small steps over many months eventually all those little problems go away - and they go away for everyone - not just Dart

@dnolen the single arity version passes nil as the first argument, and that's what is broken.

@dominicm hrm I thought nil could be passed as the first w/o issue

@dnolen it's fine for optimizations advanced.

But not for none

ok file an issue, no need to minimize since it's pretty clear

Okay, cool :)

https://babeljs.io/docs/en/babel-plugin-transform-es3-member-expression-literals could we do this when hitting a reserved name for es3?

Or do Google closure optimizations mess with that?

re: optimizing :bundle-cmd while folks can roll there own here, a lot of effort has gone into making incremental builds fast. The bundle target will be the default target at some point sooner or later and it would be a shame for everyones incremental build times to suffer behind a blunt approach.

Things to keep in mind:

re-bundles only take affect when one reloads their app from scratch

one needn’t use or rely on :bundle-cmd and can simply call their bundler from the command line whenever they want

one can use the watch option of their bundler to recompile on change

one sticky point is the initial bundling that we need in order to launch the application, as files the bundler needs don’t exist yet

I haven't actually seen a bundler without watch support yet. Maybe that's the way to go.

its just the initial build that’s kind of a bummer

If there was a bundle-fn you could use process builder to set that up.

you’re saying that you want an after-initial-build-hook kindof a thing?

yeah it seems to me bundling once at the beginning solves most of these problems

if you want to watch, start your bundler with a watcher

or if you make changes outside the scope of cljs, you can call your bundler manually

oh it should be mentioned here that this is all said in the context of in process incremental builds and the responsiveness of hot-reloading

https://ask.clojure.org/index.php/9305/wrong-command-in-the-clojurescript-quick-start

What's the best way to run a repl in the project & test building against code? Or - what's your dev setup for the cljs codebase?

Also, printlns are really not helpful eh :) They seem to end up in the output code..

you have to print standard error

there is a cljs.util/debug-prn (not sure on the namespace but I think thats right)

I was just about to say that 🙂

but bottom line it prints to standard error

Quite fun hacking on cljs stuff. Tricky, but fun :) all data-y.