Has it been considered for shadow-cljs to support auto-port allocation for the nREPL like what happens to deps.edn Main motivation would be that deps.edn doesn't support the equivalent of shadow-cljs.local.edn so the workflow to work with worktrees is not as smooth with two different solutions needed to deal with port management on a clojure/clojurescript app
shadow-cljs uses a random nrepl port by default. it only uses a fixed port if you configure it to do so. so not quite sure what you are asking?
the port is written to .shadow-cljs/nrepl.port which tools like cider/cursive understand and use automatically
Hello, why is it not possible to set :optimizations to :none for release?
I have source-maps enabled and optimization simple, and the stacktraces I see are not meaningful.
So I was hoping to have even less obfuscation/minification.
Every stack frame is just main.js with a line number that does not correspond to anything in my source.
I think this is because of this issue: https://github.com/facebook/create-react-app/issues/6667. So for my use case, skipping the obfuscation in the first place would be a better solution that obfuscating and then trying to de-obfuscate correctly across various contexts.
because thats by definition not a release build?
compile/watch are :none always, doesn't make sense to have none for release builds
In my case, I would like to prioritize debug-ability over performance even in the released environment. I would like user error reports to include meaningful stacktraces, and I don't care very much about the size of the compiled JS. Why doesn't that make sense?
then use :simple?
meaningful stacktraces you can have even with :advanced, just need to enable source maps?
:compiler-options {:source-maps true}
I mean without source maps the CLJS parts won't be very meaningful even with :none, so you really need those
well, compile is a :none optimized build, but even that I'd argue is only relevant with source maps.
also this isn't at all about obfuscating the code, its about making it smaller. not sure what create-react-app has to do with any of this though? are the CLJS outputs again processed by a different tool? in that case even :none won't help if that just drops the source maps generated by shadow-cljs, since then shadow-cljs isn't doing the shrinking but the other tool is.