This change was reverted - how to solve this problem is not entirely clear - see and for more context.

`parse-ns` assumes all information can be derived statically from the first form in the file - once macros are allowed many assumptions in the compiler go wrong. So for the time being - the complexity from the proposed change far outweighs the value this feature would have.

See regression CLJS-3311

fixed https://github.com/clojure/clojurescript/commit/a8422ee060d7d98f7578c9acb2824a5e346e7958

I added CLJS-3276-3.patch which adds a test.

Back to the other issue of slightly more dynamic require for CLJS. One rather common issue is that some namespaces should only be included in development builds but removed for release builds. One common library that has this issue is the re-frame-10x or the fulcro guardrails. They both add macros that add heavy instrumentation and have a bunch of requires. While the instrumentation can be easily disabled and skipped in the macros the initial require of those namespaces is not so easily removed and bloat the final output quite a bit with unused code which isn’t removable by DCE either.

So the common instructions include swapping out the dependency on the classpath [1] depending on what you are building. In shadow-cljs I added the :ns-aliases option [2] so that you don’t have to mess with the classpath but instead can just replace a single namespace with a stub. Both get the job done of course but I think messing with the classpath is rather unfriendly to the user.

This would be another candidate where having a slightly more dynamic require would be desirable which also cannot strictly be expressed via build tooling alone. You need the actual namespaces to provide to required code, aliased or not. I still think this is better expressed via build config though. Likely that will be used to configure whatever the “dynamic require” is supposed to do anyways, regardless if its a macro so :ns-mod.

[1]

[2]