This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-03
Channels
I'm getting an error when Cursive tries to generate stubs:
No such namespace: react, could not locate react.cljs, react.cljc, or JavaScript source providing "react" in file file:/Users/thomas/.m2/repository/thheller/shadow-cljsjs/0.0.16/shadow-cljsjs-0.0.16.jar!/cljsjs/react.cljs
I'm guessing this is because I don't have a node_modules in my base directory? I DO have one in my subdirectory and am using :js-options {:node-modules-dir "client"}
to tell shadow-cljs
where it is.
I'm wondering what the right way is to use shadow-cljsjs
. Do I need to add exclusions for deps that use cljsjs, like this?
{:deps {thheller/shadow-cljsjs {:mvn/version "0.0.16"}
fulcrologic/fulcro {:mvn/version "2.7.2"
:exclusions [cljsjs/react
cljsjs/react-dom
cljsjs/react-dom-server
@thosmos in general case, shadow-cljs just ignores cljsjs deps and looks in node_modules
cool, so maybe if I add those deps back in it won't affect shadow-cljs but will get rid of the error in Cursive. It's a cursive error.
@thosmos Cursive doesn't use shadow-cljs to generate the stubs so I suppose it uses :npm-deps
with the default compiler options
ah I guess its just compiling normally and picks those namespaces over the normal foreign-libs
i just saw that doo
supports coverage supports via istanbul
and karma-coverage
. did anybody manage to set this up with the :karma
target?
I'd probably highlight the npm integration, overall speed, simplicity and reliability (ie. no constant lein clean
or the like)
@thheller I'm one of them. For me the dynamic code loading and ease of use are super useful
@thheller also are you working on any new feature whether released or in development which you think it might be worthy to mention
ie. figwheel only does development stuff but isn't concerned with release builds much
no problem. To be honest I recently wanted to write a piece of software for my editor and i didn't want to use JVM, so I used shadow-cljs for the first time with node support,
how much more does shadow-cljs do for npm support? https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules sounds like it should work fine by now, even though my last experience was that shadow-cljs really smoothed things out
@arne-clojurians the npm support in shadow-cljs is implemented from scratch and has no relation to the article you linked or the :npm-deps
feature in CLJS
:npm-deps
is IMHO a dead end and will never work reliably enough (given the current state of wild-west JS on npm
)
even the official statement is not to use :npm-deps
and use webpack
instead these days
https://code.thheller.com/blog/shadow-cljs/2017/09/15/js-dependencies-the-problem.html
https://code.thheller.com/blog/shadow-cljs/2017/09/15/js-dependencies-going-forward.html
https://code.thheller.com/blog/shadow-cljs/2017/11/10/js-dependencies-in-practice.html
TL:DR: gave up :advanced
optimizations for npm
dependencies but instead gained almost full compatibility
so shadow-cljs does a whole lot more and is somewhat modeled after what webpack does
is there a way to trigger a rebuild on a resource change, because say I have a macro that inlines a .graphql file into my code?
at least with VSCode I can just save the file and it will touch it as opposed to emacs which requires some dirtiness
(assuming you marked the file that uses the .graphql
as uncacheable that would be enough)
@thheller I have a conceptual question. Maybe it sounds a bit naive, but why not turn things around and run the compiled clojurescript code through webpack alongside with npm modules and let webpack create the final bundle?
@achikin you can do that with :target :npm-module
. I explained my reasoning here https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html