@thheller: was thinking about the namespacing cljs.core issue again; is there any reason not to try and detect and reuse an existing cljs.core instance? supposing it has the right version

Was thinking of writing a cljs package and thought what if I end up with three cljs.cores loaded into memory!

@tgg the problem is that they must coordinate with each other

lib A loads goog/base.js

lib B also loads its goog/base.js

so if A did any modification to goog

B will override it

shadow-build will disable goog.provide for example, but proto-repl enables it again and tries to provide cljs.repl again which is an error in closure

cljs.core is not the problem

no sorry I realise that; I really meant all the cljs assets required for a reasonable runtime

but you're right

although; is there a cheap hash one can do to check for modifications? would that be a potential work around?

closure is sort of at odds with the whole node.js ecosystem

since closure expects to optimize the whole program

oh christ yeah

overlooked you saying closure there; just parsed it as clojure in my head

hrmmm

sorry; not much help at all with that!

to be quite honest

node.js packages written in cljs are far from ideal

think that's a byproduct of closure compiler?

no it isn't used

it is the way closure style code is organized

goog.provide and goog.require

is a completely different style from node require

it does feel as if there should be a more 'native' node.js approach to clojurescript

well ... 😛

the problem is that there is no "default" way to package things for node

it is all optimized for the browser

node has totally different concerns

and you really need to generate different code for the two

and the thing I did with shadow-build

doesn't really work unless everyone uses it

or sharing the cljs.core instances like you suggested

only works if everyone does

yeah 😐

if only atom had been written in cljs from the start!

yeah same story with React 😉

thanks for going over that @thheller, interesting stuff

lots to mull over

I'm not even sure how the node.js world deals with stuff like this

conflicting dependencies and such

well christ; we've all seen the dependency graphs that nodejs spits out

the thing is that you really WANT to share cljs.core instances

but how do you make sure both use the same version 😛

since libs are always lib+cljs.core

and cljs.core is not standalone

would be a great project ☝️

standalone cljs

not possible

it's fairly heavily wired into closure isn't it?

well maybe possible

but there is the whole macro side of things

it is built for whole program optimization aka closure compiler yes

funny enough there is work being done to compile ES6 type import or export stuff to closure

but not the other way arround

at least not that I have found

but I don't use node so I don't really care 🙂

😄

just annoying for hybrid stuff like atom/proton

Potential for a proton ecosystem to depend on a single/organised set of cljs.core instances though?

I certainly write now with a mind to proton > atom

well I can certainly imagine a packaging step that won't load cljs.core if it is loaded

but that again only works if everyone does it

and doesn't deal with the whole version thing

but it is just a packaging thing

for example if you run lein run -m build/release on proton

it creates a plugin.js that is just some setup code + goog/base.js + cljs/core.js etc concatenated together

ehm sorry not release the dev-repl one

release runs through the compiler

but you really don't need it since :simple doesn't do much and :advanced is pretty much impossible for node

makes sense

so if you instead of just concatenating things together

you wrap it in if (!thing.exists) { ..code.. }

there would be no conflicts

sounds feasible to me; might experiment

again only if everyone does it and you ignore versions

😄

since it completely bypasses what node and npm try to do

I hate node 😛

yeah; not a particularly big fan myself