@darwin you are the chrome extension expert: do you know if there is any way for a chrome devtools extension to talk directly to workers? I mean eval code in a running worker? I can only find things to eval in page?

@thheller I’m using latest shadow…it messed with my package.json…why?

as in: it did a thing that very likely broke my program

“It did a thing”

@dpsutton you really think “changed package.json” isn’t enough of a description?

given the delicate nature of the madness that is npm

?

Did it add a dep? Reorder them? Put white space? Remove entries? Chop half the file? Rot 13 it? Just wondering what it did.

running: yarn add --exact @js-joda/[email protected]

I spent some hours getting js-joda working right, and I don’t feel very good about my versions being messed with. I don’t know that this broke something, but it gives me a strong sinking feeling (I now have to go test things to see what might have broken), and is not what I want my build tools doing to me.

Esp at 6am before coffee 😜

what’s the diff of your package.json?

like, it was in state (a), you ran a shadow-cljs cmd, now it’s in state (b) - what’s the difference between a and b, and what command did you run?

I’d assume a cljs dependency you’re using has a deps.cljs file

@tony.kay it will only install dependencies if they aren't already in your package.json but are declared in a deps.cljs in some library you use

but there seems to be a caching problem with npm deps I haven't yet figured out https://github.com/thheller/shadow-cljs/issues/727

but shadow-cljs will not modify your package.json if the deps are already in there ... you can also set :npm-deps {:install false} in the top level of shadow-cljs.edn. then it won't even do that.

ah, ok. Good to know there’s a toggle. I figured you had thought it through…just a little jarring.

what is exactly? I mean the JS dep seems to be required right? do you want to install it yourself and have your app break?

in this case js-joda is moving from non-scoped to scoped names

and the whole mess seems a bit fragile

so if someone declares the scoped one and I am using unscoped, it gets scary

sure I get that ... but I also don't see how shadow-cljs is at fault here? 😛

now that I think of it, I upgrade shadow at the same time as some other libs…so it was certainly one of those libs that did it to me 😛

it’s early…I thought perhaps your new inspect tool wanted something in package.json or something

don't you have your package.json in git? I mean what exactly happened should be easy to tell no?

but it was the first time I saw it auto-change packge.json as well

inspect doesn't have any JS deps

it changed js-joda from unscoped to scoped and bumped the version

It certainly won't change. It may add.

oh wait…actually, I think you’re right…I think I ended up with both

which was even a bit more scary, since this is js-land

well that wouldn't be any different in JVM land either if you add a dep under a different name

well, but in js-land I don’t trust that package authors keep things out of the global space…so then I’m not sure what I have

like I said: not sure that anything broke, but just so very tired of the js ecosystem’s fragility

well its actually not that common that things end up in global somewhere but you may be passing non-scoped things to other things that expect the new scoped things

so that would be a problem but the origin seems to be in some other dep you bumped as well as shadow 😛

yeah, like I said, it was just a combo of that (changed versions on mulitple things at once), and it being the first time I’d noticed shadow changing my package.json

well, and it being 6am after getting woken up at 3am 😕

yeah, but the behavior is safe IMHO. add the dep only if it is not already listed, otherwise leave it alone.

but yeah I'm not a fan of :npm-deps in deps.cljs at all ... but also have no better ideas 😛

Cool. js-joda has add-ons (like locales) that seem to plug into the base, so changing from non-scoped to scoped seems like potential breakage.

maybe just a build error would be safer

having both seems insane

and the whole js-joda thing seems in flux…like not everything is ported yet

but yeah, in the past I’ve been perfectly happy with a build error like “react-dom” not found. Is it in your package.json? That’s what shadow used to do, right?

the :npm-deps behavior is reaaally old. it always worked like that. the only thing I added recently is the ability to turn it off.

it was added during that SoC thing, right? I think Antonio was involved as well?

I thought you had to turn it on…didn’t realize it had been on all this time. esp since I’ve seen any number of compiler errors about things missing from package.json over the years

https://github.com/thheller/shadow-cljs/commit/83ee468855725667c9a6407d72fc8b23cb661327

3 years ago .. so really not that new 😛

Love it: “[WIP] :npm-deps, still not a fan”

no this case of :npm-deps has nothing to do with the :npm-deps in CLJS

its just about installing deps nothing more

otherwise libs can't declare their npm dependencies anywhere

its also how it works in CLJS normally nowadays. it just used to do a bit more.

ah, for someone that helped you with the book and has been maintaining cljc libs for 5 years…you’d think I’d have caught up on this one 😄 So, the deps.cljs was your invention, and now adopted in regular Clojurescript? That was never clear to me. I just remember trying that early mess in stock cljs builds where it tried to do the backflips with npm.

not my invention no

that was so horrible that I just glazed over any time I see :npm-deps

just used to do more than one thing in regular CLJS. In shadow-cljs it only ever had one function.

I see…thanks for catching me up. I’ve been avoiding this topic ever since I tried to get that mess to work 4-5 yrs ago (before I discovered shadow). Been happy with the “manually manage package.json, and fix it when shadow tells me to”

yeah I guess its not nice to sneakily install new dependencies like this

I’m not a huge fan of convenience that can bust my stuff 😄

but opt-out is fine

can I use the same code base for two targets? :browser and react-native? or they are two completely different worlds?

Can webworkers connect to shadow CLJS dev server on 9630? So that we can tap> with them as well?

@neo2551 they should already do that yes.

@wvelezva thats fine yes. depends on how you want to organize the code I guess. I know some people prefer to keep it in one project and others prefer to split.

Cool! It makes it easier to use them haha. I wonxer if we could even hook re-frame-10x to them.