Fork me on GitHub
#shadow-cljs
<
2021-06-04
>
diego.videco06:06:11

I am trying to create a library that is going to be included in a script tag in another shadow-cljs project. The problem I am facing is that it seems that a shadow$provide global variable is created for each build, and because of this, the second variable overwrites the first one producing a Module not provided. I've tried the :browser and the :node-library targets and both of them seem to have the same problem. What is the best way to get around this?

thheller06:06:54

@diego.vid.eco it is not a good idea to use 2 separate CLJS builds on the same page. both will end up including cljs.core and all other dependencies leading to a lot of bloat. they also won't be compatible with each other and can't exchange CLJS datastructures. ideally make the library part of the compilation of the second one, like any other CLJS libs.

diego.videco06:06:15

I see. And it makes sense. I originally wanted to develop a couple of plug-n-play libraries for an art project, where also others could plug in their own developments. So that's why I didn't intend to have them "installed" by default on the hosting webpage. Seems like I may have to reconsider some things, but might not be much of a problem.

thheller06:06:47

yeah unfortunately there is no way to really do this properly in CLJS. even if I isolated shadow$provide more that doesn't fix all the other problems you'd have.

thheller06:06:37

JS has the same issues if you have 2 libs using immutable-js or so. things can talk to each other fine with just JS objects but everything else breaks.

danielneal08:06:28

is it possible to have multiple shadow-cljs builds with different dependencies. i.e. I want to produce a js npm package (that doesn't depend on react, helix etc) and a cljs live-reloading demo of the package (that does depend on react, helix etc), but preferably from the same overall project

thheller08:06:15

npm library as-in it will be consumed by JS projects?

thheller08:06:17

in general your dependencies decide nothing about the build. the build config controls how or what is included, not the dependencies you have listed in your project

thheller08:06:56

what is a live-reloading demo? for people checking out the repo and running it locally you mean?

danielneal08:06:52

yep, the npm library will be consumed by js projects

danielneal08:06:32

the live-reloading demo is exactly for the cljs devs so that we can check out the lib and make modifications to it and see it in action

thheller08:06:32

not including react is fine but helix is a CLJS lib so you need to include that no?

thheller08:06:39

to build the library you can use :target :node-library or :target :npm-module, those by default don't bundle JS dependencies, only compiled CLJS code

danielneal08:06:25

I'll have a go 🙂

thheller08:06:49

made that a long time ago. config is unchanged though. just need to bump a few versions

thheller08:06:19

basically you add the dependencies of the package in the packages/demo/package.json

thheller08:06:31

and publish the packages/demo dir using npm publish

danielneal08:06:23

the :entries key is a list of clojurescript namespaces to include in the npm package?

danielneal08:06:37

great, thanks

Franklin08:06:51

can shadow-cljs also watch and hot-reload css?

thheller08:06:04

watch as in observe when the file changes yes

Franklin08:06:26

yes, so I'm hoping that when I change them... the styling on the browser also changes

Franklin08:06:54

cool, thanks

myguidingstar13:06:57

how do I use latest shadow-cljs from github?

thheller14:06:04

unfortunately not that simple. can't use deps.edn because there is some stuff that needs to be built (eg. java sources).