Clojurians Log v2
cljdoc
hi 👋 I'm requiring a namespace from an npm module loaded with shadow-cljs, what do I have to do to make it work with cljdoc?
(a bit off topic, but related: is shadow-cljs basically a different dialect of CLJS? what if you write a lib in that, can normal CLJS not consume it? feel free to respond on a thread)
Hi Joel! 👋 I think unless we switch the underlying analyzer to shadow's implementation there's nothing easy we can do here
If this is a library I would recommend to use plain CLJS because otherwise all consumers will be required to use shadow-cljs as well (might be ok but certainly a smaller user-pool)
Yeah, I think that's pretty much correct /cc @thheller
it's not a library, the cljs files can be used by child projects but it's not their main usecase. in this case the cljs is the backoffice of an ecommerce site, and this dependency is only going to be used to build sites /extend the software
but, can the cljs be ignored? so that my clj sources are analyzed and the documentation is picked up
don't care that much about the cljs part, it's not documented anyway
also can it stop using the dev profile?
@joelsanchez there's no concept of profiles in cljdoc's analyzer. We look at a projects pom file (http://repo.clojars.org/ventas-core/ventas-core/0.0.13/ventas-core-0.0.13.pom) and try to include some additional dependencies that a project might need.
Eg. some namespace might need core.async but it's expected that the user provides it. Often these kinds of dependencies can be found in the pom with <scope>test</scope> etc
ah sorry. so can the cljs files be ignored?
selecting platforms isn't supported for users at this stage but I can hardcode it for you if you want
well, sure 🙂
(have done so for other projects, would be no problem)
"ventas-core/ventas-core" is correct?
no, just ventas-core
I should have called it joelsanchez/ventas-core but I haven't. so...
ok (that's the same)
Maven has group and artifact IDs. In Clojure when you have a project ID that doesn't contain a / it implies that they're both the same
learning every day... 😛
😄
didn't know this for a long time either (and it's not really all that useful to know hahaha)
no that is incorrect. shadow-cljs is a build tool for clojurescript. the language stays the same with one little exception: https://dev.clojure.org/jira/browse/CLJS-2376 this is already implemented
And this is the exception Joel runs into I guess?
reading ...
nope that is completely standard. I'm guessing that the npm dependencies just aren't installed?
@martinklepsch this should work fine if you respect deps.cljs and install the dependencies listed there
yeah, I guess that's the issue then
Sorry for the confusion here @thheller and thanks for chiming in
this might work?
the problem is that CLJS needs to index the node_modules directory to understand that "react-color" is a npm dependency.
I'm not sure if there is a setting to just make it ignore any string deps? I think :target :nodejs does something to that extent? I'm not actually sure how any of this works in default CLJS anymore
since you only analyze and not actually compile it would be fine to just ignore the string deps and treat them as a plain JS object
you could probably add something that doesn't actually require installing the deps
node_modules is gitignored so they won't be installed by default
there is a package.json with react-color and the other deps though
I guess cljdoc would have to install them?
sorry, git is irrelevant, but node_modules is not inside resources and not in the artifact at all
I should have some time tomorrow, maybe I can figure something out that cljdoc parses these properly
Thomas gave some more context on that in the other thread
that would be super nice 🙂 otherwise I might get to it eventually 🙂
👍
thank you both @thheller @martinklepsch for your help and for your outstanding projects
@martinklepsch can you point me to the code that does the analysis? the function that starts it all?
https://github.com/cljdoc/codox/blob/cljs-proper/codox/src/codox/main.clj
That namespace has a -main. What you'll need to do to play with that is:
1. Unpack the contents of the dependency's jar into a directory
2. Add it as a dependency to the local deps.edn
then you should be able to run something like clj -m codox.main clojurescript jar-contents-dir
It's a little fiddly, let me try to push a commit with some inline docs/pointers for this
its fine. already saw what I needed 😉
https://github.com/cljdoc/codox/commit/b29b16ae686e3400689bbdc93df57200b709443d
finally finished writing that blog post I've been thinking about for a while ... maybe it clears up some of the confusion: https://code.thheller.com/blog/shadow-cljs/2019/03/01/what-shadow-cljs-is-and-isnt.html
One thing I didn’t get is that you’re referring above to CLJS-2376 which introduces this string syntax in require, and that shadow-cljs already implements this. But CLJS-2376 is not yet in CLJS master it seems, so the language is in that aspect still different?
CLJS-2376 introduces :default not the string requires. string requires have been implemented for a while
ok thanks
https://github.com/clojure/clojurescript/commit/dd5d86223f359e06434a152ad0ea5e0bee317459
@martinklepsch I made some adjustments to the codox stuff so that string requires work without actually having to install npm dependencies. https://gist.github.com/thheller/5bc57a7571cf83fd12190ab7165cdb46
the main difference is that the compiler state is only created once in read-namespaces instead of re-creating it all the time
as that re-analyzes all the deps all the time
problem is that it won't fix (:require [react-color ...]) since its a symbol
another strategy could be reading all deps.cljs files for :npm-deps and creating the fake :js-module-index entry for each (maybe package.json too)
then the symbol would work too