@bhauman re: :bundle-cmd this just exactly the kind of thing I'm not interested in working on since it's very unclear what's needed and whatever we choose might not be right in all scenarios - I don't have this problem with React Native in medium size application.

and it just seems too straightforward to fix it in Figwheel or any other tool if the tool designer wants some specific semantic

maybe you're agree with this sentiment, not completely sure reading over the backlog

but I would say the first question everyone should ask themselves is "maybe I shouldn't use :bundle-cmd ?"

and then your problems go away

@dnolen just to clarify, the rn bundler doesn't care about your :output-to existing for the first run

fwiw, I've ended up having to hack something to run in a figwheel post-build-hook which will start a process if it's not already running 🤕. It's a bit hacky.

right but why bother?

just start the watcher first manually

@alexmiller website needs a bump for that AskClojure question

Because people generally expect to be able to rock up at a project and jack-in without having to open a bunch of terminals to get all of the 5 processes they need running to run a project.

But also, I don't think the watcher can be started first manually.

modern JS development isn't like that anyway

Yeah, it can't. You have to wait until after the first cljs build.

there's already multiple steps

and you're using a bundler which you can't abstract away

anyways just not interested right now, :bundle-cmd isn't going to see any further enhancement

I said this when I added it

I'd rather see some other tool work on this problem - discover all the issues before investing any more time in it

OK. Well, I can sorta do my own bundle for now with figwheel.

@dnolen I think @dominicm is saying that React Native bundler doesn’t require the output-to artifact at the start while webpack does. So it makes start up a little tricky, ie you can’t pop a browser client open as you have to start webpack after your first cljs compile.

For this reason I’m thinking that :bundle-cmd should run just once for a watched build, as it handled the awkwardness of getting started and doesn’t incur the unneeded cost on incremental compiles. One can just restart the process, or start webpack with a --watch flag, if needed.

right but I'm trying to say in this scenario why not just not use it

start the watcher, run your CLJS tool

the problem goes away

I stated why in the preceeding paragraph

you can’t start the watcher first

the webpack watcher doesn't just keep watching for index.js

i.e. the watcher exits if it can't find it?

yep

so you have to start cljs first

and then start the watcher and then reload your browser

what happens in webpack if you delete`index.js` while watching?

anyways it stuff like this that makes doing anything here super annoying

which is why I'm not that interested

or rather see it sorted out elsewhere first

because it's going to be a time hole

Yes thats what I was thinking as well, and starting with just bundling on the first compile to facilitate launching repls etc.

as its a simple straightforward behavior

but what if you use a different bundler that just doesn't have this problem and you want to build something that just refreshes on npm deps changes etc.

anyways doing stuff mean less flexibility downstream

I just don't like it sorry

:bundle-cmd should make no choices

> "maybe I shouldn't use `:bundle-cmd` ?" i was thinking that bundle-cmd will be the default and you need to know that you will never need npm deps to not use it?

then everybody can make their own and do more interesting things for their other tooling choices

my 2c: running :bundle-cmd once after the first successful compile seems the most unopinionated way of doing this

solves the problem w/ tools expecting input at process start, and lets you build the rest yourself if you want something fancier

it’s onerous to build a tool on top that waits for your bundle to be created and then start another process

on the other hand, if your tool (like metro) doesn’t care whether it’s there or not it’s still fine to wait until after the succesful build

@dominicm the other reason this doesn't seem like a real problem you can make your own index.js that includes :output-to

add a layer of indirection

or does webpack watcher expect everything to be perfect on the first build - which seems ... wat

it seems like a simple way to make it robust for the majority of cases

we can’t control all the different behaviors of the tools out there, but we can control the behavior of CLJS to ensure that code is on disk before it starts up at least

that's not the problem under discussion?

there is not problem with :bundle-cmd

what we're talking about is specifically the behavior of webpack watching

if all you need is a separate index.js so just the watcher can start - there is nothing meaningful for CLJS to do here

this is exactly how Krell works

we make an index.js file once

but you can't do that for ClojureScript anyway because the contents can in fact change

we could do a similar thing just for :bundle , :bundle-entry or something similar

This is only for w watched build, and these changes are rare and are the kinds of changes that normally require a restart

a restart of what? the REPL?

of the repl build process

adding a package for instance

adding a preload

it's not necessarily true for packages

In Krell you can just refresh, and the REPL handles reconnects

things that one would expect might need a restart

there's no reason that can't happen in the browser too

you have to refresh, but you don't need to restart build or REPL

Just trying to preserve the start up experience and the super quick reloads the folks have come to expect, that’s why I’m going to bundle once at the beginning. And they can start a watcher in parallel if they need it.

there will be a flag if they want to bundle every time

this seems perfectly fine for Figwheel to do it this way

I've been saying that over and over again

this is what I did in Krell

the tool can make the decisions for the specific integration the creators believes will be most useful

ClojureScript doesn't give a damn about Webpack

Testing out other web bundlers, parcel also exits if the entry file doesn’t exist. If a transitive file doesn’t exist, then it shows a loud error (but continues to watch).

you can use Metro to build web stuff, it doesn't have this problem

anyways I could go on - but there's just not good reason to do anything just yet IMO

er, well that's not true, you need index.js

not surprising

but this thing is not a ClojureScript file

it never changes

part of the issue is really there's several different problems under discussion

anyways not convinced it's practical to untangle all these things since the specter of convenience / end user expectation is interwined

I don't really like :bundle-cmd being one-shot because nothing else in the compiler config has this semantic

:install-deps has the same problem

and the answer there was the same - you probably don't want it

the other problem is that these issues are dev issues, :bundle-cmd and :install-deps may very well be what you want for prod.

my biggest issue is that people lose the current start up behavior (repl connection, browser open) if they opt out of the :bundle-cmd

so maybe we need something generic an after-build-hook

for Figwheel this is a UX thing - I get that

well cljs has the same UX

it lauches a repl

oh that doesn’t work with the :bundle target

it does work

clj -m cljs.main -c -r variants work

and :bundle is only going to run once

so you don't have these problems

if you add a watcher?

bundle only runs once?

anyway its interesting that the REPL works

no, not going to change this (the watcher case) because of your better idea for hot-reloading

@bhauman there's a been a bunch of fixes to cljs.cli because of user feedback here

cool I’m going to check those changes out and get up to date 🙂

@bhauman another fix is that :main is analyzed now on separate thread when you start REPL

that was a recent change

yes

but all of this informed by -c -r

usage

you compile once, and then you start a REPL, and the REPL takes everything from build

hot-reloading would answer any remaining issues

Have you thought about bundle for the hot reload? Would that be run once or run per reload?

I alluded to this above but probably not clear

Hmm, maybe I figured it out. But explicit is better :)

we're not going to run :bundle-cmd except where we run it now

at the end of a build

hot-reload generally doesn't need to do anything but the file that changed and its dependents

... but

the requires may have changed, and we could recompute npm_deps.js which is the required node_modules

in this case a watch process is going to be better anyway (because it will know that npm_deps.js has changed)

you will also need a refresh and a REPL that will reconnect on refresh

so long answer - I'm not sure we should re-run it

but making :bundle-cmd more useful for watching workflow seems interesting - i.e. we don't wait for :bundle-cmd to return but just start a process (but has a lot of downsides for logging)

Hmm. So maybe figwheel should clear :bundle-cmd for subsequent builds then - to mirror that proposed behavior.

Not sure what Krell does.

it doesn't need :bundle-cmd because you must run npx react-native start anyway

having that run inside of :bundle-cmd even if we supported it has too many downsides, which why I don't even really like it for the REPL scenario above

I see.

yeah the problem with triggering a bundle watcher inside ClojureScript is directing the output

the output is also colorized so that has to be configured

this is true for :bundle-cmd right now too, for very simple builds it's sufficient

but I'm skeptical about more complicated builds w/ lots of plugins whether you really want to see the failures in a Clojure stack trace

though maybe we should/could do what RN does - automatically open a new terminal for running that command?

Personally having one place for it to go (i.e. in my REPL / terminal) is better than checking N places on failure. I actually have non-devs (CEO & designers) working on my Cljs project - so I want to minimize their pain. In a past life I was a consultant, so I made a conscious effort to make sure I could switch projects without having to think about it.

I... wonder how it does that. At least on Linux, good luck figuring out: - What my terminal is - How to run it to spawn a new command - Whether I prefer tabs, splits or new windows for my terminal

sure I get that just, throwing out thoughts

For sure, good to explore everything. I think the only way to work that is something like a ~/.cljs-terminal.edn where I could configure what I want to have happen

One worry I have here is fragmentation. I know eventually cljs upstream will merge what works. But in the interim we'll have a few competing solutions to this problem. That just makes things more complex for people trying to use react-select in their project.

honestly that seems unavoidable - and has been true for a long time anyway

and IMO is in fact desirable - letting tools innovate and folding back in what works is slower but also more sustainable