This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (9)
- # atom-editor (29)
- # aws (17)
- # babashka (72)
- # beginners (83)
- # braveandtrue (3)
- # calva (7)
- # cider (16)
- # clj-kondo (15)
- # cljs-dev (146)
- # cljsjs (1)
- # cljsrn (8)
- # clojars (1)
- # clojure (96)
- # clojure-dev (19)
- # clojure-europe (53)
- # clojure-losangeles (1)
- # clojure-nl (3)
- # clojure-spec (7)
- # clojure-uk (235)
- # clojuredesign-podcast (5)
- # clojurescript (81)
- # conjure (73)
- # cursive (7)
- # data-science (1)
- # datomic (5)
- # defnpodcast (8)
- # emacs (3)
- # figwheel-main (34)
- # fulcro (83)
- # graalvm (10)
- # graphql (6)
- # helix (49)
- # jackdaw (3)
- # jobs (1)
- # joker (1)
- # kaocha (1)
- # mid-cities-meetup (10)
- # off-topic (17)
- # pathom (16)
- # re-frame (11)
- # reagent (18)
- # reitit (18)
- # remote-jobs (4)
- # shadow-cljs (63)
- # spacemacs (18)
- # specter (20)
- # sql (17)
- # uncomplicate (1)
- # vim (28)
- # xtdb (32)
: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
but I would say the first question everyone should ask themselves is "maybe I shouldn't use
@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.
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.
anyways just not interested right now,
:bundle-cmd isn't going to see any further enhancement
I'd rather see some other tool work on this problem - discover all the issues before investing any more time in it
@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.
Yes thats what I was thinking as well, and starting with just bundling on the first compile to facilitate launching repls etc.
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.
> "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
or does webpack watcher expect everything to be perfect on the first build - which seems ... wat
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
if all you need is a separate index.js so just the watcher can start - there is nothing meaningful for CLJS to do here
but you can't do that for ClojureScript anyway because the contents can in fact change
This is only for w watched build, and these changes are rare and are the kinds of changes that normally require a restart
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.
the tool can make the decisions for the specific integration the creators believes will be most useful
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).
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
the other problem is that these issues are dev issues,
: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
no, not going to change this (the watcher case) because of your better idea for hot-reloading
@bhauman another fix is that
:main is analyzed now on separate thread when you start REPL
Have you thought about bundle for the hot reload? Would that be run once or run per reload?
hot-reload generally doesn't need to do anything but the file that changed and its dependents
the requires may have changed, and we could recompute
npm_deps.js which is the required
in this case a watch process is going to be better anyway (because it will know that
npm_deps.js has changed)
: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.
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
yeah the problem with triggering a bundle watcher inside ClojureScript is directing the output
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
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.