Fork me on GitHub
#shadow-cljs
<
2018-12-06
>
biscuitpants07:12:26

has anyone had a problem with using shadow-cljs with cljsjs packages?

biscuitpants07:12:46

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

thheller09:12:05

@biscuitpants cljsjs packages are not supported at all and must be emulated. https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs

biscuitpants09:12:01

ok so absolutely zero compatiblity. that’s all good

thheller09:12:37

happy to take a PR to add the shim file here https://github.com/thheller/shadow-cljsjs

thheller09:12:47

the most common cljsjs packages are already emulated I guess

biscuitpants09:12:27

oh nice! didn’t know about that repo

biscuitpants14:12:33

how would i add a dev file to builds, only during dev time? so an extra ns to load when doing dev

thheller14:12:21

@biscuitpants :devtools {:preloads [foo.bar]}. as of recently individual modules also accept preloads, eg. :modules {:foo {:preloads [...]}}

pez16:12:52

@thheller: This node-repl thing is perfect for my npm module in the making! Here testing the coming Calva support for it. Thanks again!

pez16:12:55

I choose to make it selectable this way:

thheller17:12:51

@richiardiandrea lets continue here. no need to spam #clojurescript 😉

thheller17:12:44

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?

richiardiandrea17:12:41

so yeah lib B is a CLJS lib which contains deps.cljs

richiardiandrea17:12:51

lib A is the consumer

thheller17:12:26

so strictly speaking its not a library at all?

richiardiandrea17:12:36

lib B is - lib A no

richiardiandrea17:12:50

so let's say lib B and cons A 😄

thheller17:12:57

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

thheller17:12:09

otherwise the next time you run npm install it might have a completely different set of deps

richiardiandrea17:12:31

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

richiardiandrea17:12:07

my only issue is when I build cons A - the deps.cljs dependencies gets added to its package.json

thheller17:12:07

but you want them in there? I don't understand why that is a problem?

thheller17:12:39

> otherwise the next time you run npm install it might have a completely different set of deps

richiardiandrea17:12:00

so it feels like as if I had a project.clj which is modified by the transitive dependencies of lib A

thheller17:12:25

stop using "lib A" .. just use A please. it is confusing enough as it is.

👍 4
thheller17:12:59

ok so lets make a rather simple scenario

thheller17:12:21

B declares {:npm-deps {"react" "^16.0.0"}}

thheller17:12:47

A uses B and no package.json is not updated and no package-lock.json is created at all

richiardiandrea17:12:02

it does, that is the problem

richiardiandrea17:12:11

in the A project

thheller17:12:11

you run npm install in the project NOTHING is installed

richiardiandrea17:12:30

I think it does here 😄

thheller17:12:36

package.json of A is presumably empty

richiardiandrea17:12:43

that is why I had to add the flags

richiardiandrea17:12:05

let me see one sec

thheller17:12:17

shadow-cljs was not executed yet

thheller17:12:31

I actually talking about npm install. we can agree that nothing happens yes?

thheller17:12:55

so your code cannot execute since the dependencies are not installed?

thheller17:12:12

so you NEED to execute shadow-cljs in order to run your code

thheller17:12:18

that seems like problem to me?

richiardiandrea17:12:58

I have to use shadow in order to install the transitive deps for sure, because A does not declare them

thheller17:12:04

also :install-cmd lets you do this already. I'm not changing the default.

thheller17:12:40

the reason they need to be put into package.json of A is partly due to tooling

thheller17:12:51

say you do npm install something-a-wants

thheller17:12:14

it may actually REMOVE everything that was installed via B deps.cljs since its not in package.json

richiardiandrea17:12:42

does JS tooling rely on package.json or on node_modules? because the deps will be in node_modules...

richiardiandrea17:12:52

sorry silly question, not a JS expert here

richiardiandrea17:12:06

kk in that case than I see why you would want that

thheller17:12:29

the situation is messy enough as it is and I never liked :npm-deps

richiardiandrea17:12:30

I am coming from Clojure/Java where you only inspect that classpath I guess

richiardiandrea17:12:05

perfect thanks for your patience and explanation, I was sure there was some reason there I was missing

thheller17:12:31

you can't compare clojure since we are trying to "merge" 2 different package managers here

thheller17:12:52

we need to collect classpath dependencies for CLJ(S) and then a secondary set of deps for npm

thheller18:12:01

but npm doesn't know how to read the first set

thheller18:12:12

so we need to move it out of there to something that npm can understand

thheller18:12:15

thus add it to package.json

richiardiandrea18:12:28

gotcha that makes perfect sense now

thheller18:12:30

I don't know how to do this cleaner

richiardiandrea18:12:42

I guess I just needed to understand why 😉

thheller18:12:04

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.

thheller18:12:14

I just want something a little more predictable.

richiardiandrea18:12:52

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

richiardiandrea18:12:12

so I am going to use the default for the time being

thheller18:12:16

well that adds a third thing. no idea what Azure does.

richiardiandrea18:12:35

yeah but the explanation you gave me make sense anyways 😉

thheller18:12:14

tooling generally uses package.json to resolve version conflicts and such

thheller18:12:27

or rather uses package-lock.json in case of npm

thheller18:12:59

to kinda ensure that running npm install is at least semi consistent given the widespread use of version ranges in the npm world

👍 4
richiardiandrea23:12:52

Has anything changed with the way :azure-app's :fn-map gets emitted? I have a weird error with 2.7.8

richiardiandrea23:12:06

[error] Worker was unable to load function trigger: 'TypeError: Cannot read property 'trigger' of null'.

richiardiandrea23:12:59

woah ok, all our functions seems broken 😅