You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if the tool could be also used on Clojurescript projects.
It seems that tools.namespace suuports cljs. I did a quick experiment and was able to make it parse cljs files by replacing (namespace.find/find-ns-decls-in-dir file) with (namespace.find/find-ns-decls-in-dir file namespace.find/cljs) in parser.clj. So it should be possible to expose it up with some kind of option.
Following that I encountered circular dependency issue when namespaces require macros which halts the analysis.
For example foo.cljs:
(nsfoo
(:require-macros [foo]))
or foo.cljc:
(nsfoo
#?(:cljs (:require-macros [foo]))
There does not seem to be a way to override how tools.namespace treats circular dependencies, but I found a workaround by wrapping a line in dependency.clj in try/catch and ignoring circular dependencies. I don't see much value for the analysis tool to check circular dependencies in Clojure given it is already enforces that. But perhaps there could be an option for that.
With that I was able to make the analysis work. What probably needs some thinking is how to expose the option. Whether to specify it globally or just per layer(s). I am thinking for full-stack projects that consist of server clj code, client cljs and shared cljc, it would be useful to check all dialects at the same time.
The text was updated successfully, but these errors were encountered:
What probably needs some thinking is how to expose the option
About this point would be when someone wants to enable parsing only one or the other, right?
Do you see any side effects of always considering both by default (clojure.tools.namespace.find/clj and clojure.tools.namespace.find/cljs)?
What comes to mind at first is just more processing consumption 🤔
BTW, if we are going to put this at the configuration level, I would put a property at the global level that by default would be both platforms, and that would also allow overwriting at the layer level.
This property looks something like this: :platform #{:clj :cljs}.
I'll open a PR as a proof of concept to see how it looks.
Do you see any side effects of always considering both by default (clojure.tools.namespace.find/clj and clojure.tools.namespace.find/cljs)?
What comes to mind at first is just more processing consumption thinking
I like your thinking, it does make sense to me to start with two separate passes by default.
The perf penalty is that filesystem is traversed twice, and cljc files will likely get parsed twice.
But if it turns out it will work feature-wise, it can be optimized later.
BTW, if we are going to put this at the configuration level, I would put a property at the global level that by default would be both platforms, and that would also allow overwriting at the layer level.
This property looks something like this: :platform #{:clj :cljs}.
I was wondering if the tool could be also used on Clojurescript projects.
It seems that tools.namespace suuports cljs. I did a quick experiment and was able to make it parse cljs files by replacing
(namespace.find/find-ns-decls-in-dir file)
with(namespace.find/find-ns-decls-in-dir file namespace.find/cljs)
in parser.clj. So it should be possible to expose it up with some kind of option.Following that I encountered circular dependency issue when namespaces require macros which halts the analysis.
For example foo.cljs:
or foo.cljc:
There does not seem to be a way to override how tools.namespace treats circular dependencies, but I found a workaround by wrapping a line in dependency.clj in try/catch and ignoring circular dependencies. I don't see much value for the analysis tool to check circular dependencies in Clojure given it is already enforces that. But perhaps there could be an option for that.
With that I was able to make the analysis work. What probably needs some thinking is how to expose the option. Whether to specify it globally or just per layer(s). I am thinking for full-stack projects that consist of server clj code, client cljs and shared cljc, it would be useful to check all dialects at the same time.
The text was updated successfully, but these errors were encountered: