This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-06
Channels
- # adventofcode (112)
- # announcements (6)
- # beginners (197)
- # boot (3)
- # calva (52)
- # cider (25)
- # clara (14)
- # cljdoc (6)
- # clojure (147)
- # clojure-austin (6)
- # clojure-berlin (7)
- # clojure-brasil (2)
- # clojure-europe (3)
- # clojure-india (4)
- # clojure-italy (8)
- # clojure-new-zealand (2)
- # clojure-nl (7)
- # clojure-russia (7)
- # clojure-spec (29)
- # clojure-uk (63)
- # clojurescript (103)
- # core-async (5)
- # cursive (11)
- # datomic (16)
- # devcards (1)
- # emacs (28)
- # figwheel-main (3)
- # fulcro (97)
- # graphql (4)
- # hyperfiddle (1)
- # jobs (1)
- # kaocha (3)
- # lumo (9)
- # nrepl (4)
- # off-topic (29)
- # onyx (1)
- # pathom (4)
- # pedestal (8)
- # re-frame (24)
- # reagent (1)
- # reitit (13)
- # ring-swagger (7)
- # rum (11)
- # shadow-cljs (79)
- # sql (46)
- # tools-deps (67)
- # yada (8)
has anyone had a problem with using shadow-cljs with cljsjs packages?
one of our projects still uses lein, and brings in a cljsjs package. no matter how i configure deps, shadow cannot find the dep for some reason
@biscuitpants cljsjs packages are not supported at all and must be emulated. https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs
ok so absolutely zero compatiblity. that’s all good
thank you!
happy to take a PR to add the shim file here https://github.com/thheller/shadow-cljsjs
oh nice! didn’t know about that repo
how would i add a dev file to builds, only during dev time? so an extra ns to load when doing dev
@biscuitpants :devtools {:preloads [foo.bar]}
. as of recently individual modules also accept preloads, eg. :modules {:foo {:preloads [...]}}
@thheller: This node-repl
thing is perfect for my npm module in the making! Here testing the coming Calva support for it. Thanks again!
@richiardiandrea lets continue here. no need to spam #clojurescript 😉
so when you say "lib A" and "lib B" I read CLJS lib A+B. is that correct or are you talking about npm libs?
so yeah lib B is a CLJS lib which contains deps.cljs
lib A is the consumer
lib B is - lib A no
so let's say lib B and cons A 😄
so A is the thing that will actually be executed? in that case you definitely want a package-lock.json with all the deps in package.json
otherwise the next time you run npm install
it might have a completely different set of deps
yep I have a package-lock.json
in lib A and I am ok with that and I like the warning when deps.cljs
is out of sync
my only issue is when I build cons A - the deps.cljs
dependencies gets added to its package.json
> otherwise the next time you run npm install
it might have a completely different set of deps
so it feels like as if I had a project.clj
which is modified by the transitive dependencies of lib A
A uses B and no package.json is not updated and no package-lock.json is created at all
it does, that is the problem
in the A project
well no?
I think it does here 😄
that is why I had to add the flags
let me see one sec
agreed
agreed
I have to use shadow
in order to install the transitive deps for sure, because A does not declare them
it may actually REMOVE everything that was installed via B deps.cljs
since its not in package.json
does JS tooling rely on package.json
or on node_modules
? because the deps will be in node_modules
...
sorry silly question, not a JS expert here
kk in that case than I see why you would want that
I am coming from Clojure/Java where you only inspect that classpath I guess
perfect thanks for your patience and explanation, I was sure there was some reason there I was missing
you can't compare clojure since we are trying to "merge" 2 different package managers here
we need to collect classpath dependencies for CLJ(S) and then a secondary set of deps for npm
gotcha that makes perfect sense now
I guess I just needed to understand why 😉
you can try to work with your custom :install-cmd
. maybe it works for you. I never used npm
that way. it may actually work.
but no yeah, if you say that npm
relies on both, I need to carry them over cause I am relying on JS tooling like the Azure stuff
so I am going to use the default for the time being
yeah but the explanation you gave me make sense anyways 😉
to kinda ensure that running npm install
is at least semi consistent given the widespread use of version ranges in the npm world
Has anything changed with the way :azure-app
's :fn-map
gets emitted? I have a weird error with 2.7.8
[error] Worker was unable to load function trigger: 'TypeError: Cannot read property 'trigger' of null'.
woah ok, all our functions seems broken 😅