The usage of macros from CLJS is very explicit and users of any given namespace must remember whether it comes with macros and which vars are macros. This leads to rather verbose :require statements which are confusing and lead to unexpected results if incomplete (eg. missing :refer-macros).
(ns my-ns
(:require [my-app.other-ns :as other :refer (something) :refer-macros (something) :include-macros true]))
(something) ;; macro (when :refer-macros, otherwise no macro)
(other/thing) ;; maybe macro (only when :include-macros, otherwise no macro)
I think the user should not need to know whether something is a macro or not, they should just be able to use it.
will work just find and do the correct thing with regards to macros (assuming the namespace has a corresponding clj namespace, :require-macros is unaffected). No changes to any code are necessary as the implementation uses ana/passes, it is also fully backwards compatible.
Implementation points which should be discussed
The CLJS namespace with macros currently has to opt-in through a bit of metadata (eg. (ns my-ns-with-macros {:load-macros true})), that might not be necessary and maybe should default to true.
The implementation assumes compilation happens in dependency order. shadow-build always does this, I'm not too sure about CLJS though. Given ana/analyze-deps equals true that is guaranteed but I'm not sure that is always the case.
If there is any interest I can provide a patch, until then refer to the proof-of-concept [1].
Major
The usage of macros from CLJS is very explicit and users of any given namespace must remember whether it comes with macros and which vars are macros. This leads to rather verbose :require statements which are confusing and lead to unexpected results if incomplete (eg. missing :refer-macros).
(ns my-ns (:require [my-app.other-ns :as other :refer (something) :refer-macros (something) :include-macros true])) (something) ;; macro (when :refer-macros, otherwise no macro) (other/thing) ;; maybe macro (only when :include-macros, otherwise no macro)I think the user should not need to know whether something is a macro or not, they should just be able to use it.
I implemented a proof-of-concept that
(ns my-ns (:require [my-app.other-ns :refer (something)])will work just find and do the correct thing with regards to macros (assuming the namespace has a corresponding clj namespace, :require-macros is unaffected). No changes to any code are necessary as the implementation uses ana/passes, it is also fully backwards compatible.
Implementation points which should be discussed
The CLJS namespace with macros currently has to opt-in through a bit of metadata (eg. (ns my-ns-with-macros {:load-macros true})), that might not be necessary and maybe should default to true.
The implementation assumes compilation happens in dependency order. shadow-build always does this, I'm not too sure about CLJS though. Given ana/analyze-deps equals true that is guaranteed but I'm not sure that is always the case.
If there is any interest I can provide a patch, until then refer to the proof-of-concept [1].
[1] https://github.com/thheller/shadow-build/blob/f37cfa598f1e90dd66e333d1e45580ea25650025/src/clj/shadow/cljs/passes.clj#L30-L82