Fork me on GitHub
Sam Ritchie14:06:51

hey all, gut-check question here… I have a library I’d like to depend on that is currently managed with bower: If I want to publish a clojurescript library that depends on this package… is the best option to re-publish this as an NPM dependency? I am getting my head around all of this, and it seems that bower is deprecated

Sam Ritchie14:06:18

I guess the alternative that comes to mind is cljsjs, or including the js files directly (seems very un-pro)


for shadow-cljs you'd need to publish to npm since cljsjs is not supported. should be very simple since bower is very similar to npm as far as packages are concerned


in fact shadow-cljs can also use bower packages just fine, just needs a little extra configuration in :js-package-dirs

Sam Ritchie16:06:11

is there any docs page that lays out what to do? otherwise I will go down the NPM road


well since you mentioned publishing a library that depends on mathbox I strongly recommend publishing to npm


otherwise everyone using that package would need to manually install bower and that package


with npm it just works automatically if you list it in deps.cljs

Sam Ritchie16:06:47

got it, that is clearly best


:js-packages-dirs ["node_modules" "bower_modules"] IIRC bower used that dir?


but to publish the thing to npm you likely only need to change the name in package.json and npm publish


dunno if its a good idea to use a 5 year old JS package with version 0.0.5 though. It is not clojure after all 😛

Sam Ritchie17:06:07

@thheller in most cases I would agree.. BUT!

Sam Ritchie17:06:34

in this case, this library still seems to be the most world-class thing out there for mathematical visualization in the browser... it powers as an example

Sam Ritchie17:06:19

@unconed has this insane level of work in this project, but stalled because he'd developed something wonderful but "javascript as a language didn't seem to fit for the declarative XML-ish structures he'd based the library on" 😉

Sam Ritchie17:06:40

so I'm going to rehab this thing and get him interested again. Anyway, TMI for the main thread, but cool stuff!

Sam Ritchie18:06:04

@thheller one Q for you related to cljsjs. I've published mathbox as I want to provide a :global-exports entry that will make this package compatible with shadow-cljs. but the boot task in cljsjs needs a map of sym=>sym for its :global-exports value. what should the value be here?

:global-exports '{"@sicmutils/mathbox2" MathBox
                  cljsjs.mathbox2 MathBox}

Sam Ritchie18:06:21

I can always republish it without the @ symbol... but I don't want to stomp the global mathbox2 name, for when the original author pushes this out


I don't understand your question. shadow-cljs does NOT support foreign-libs, so whatever you add there will not be read by shadow-cljs at all?


does (:require ["@sicmutils/mathbox2" :as x]) not work?

Sam Ritchie18:06:44

ah, I think I have this figured out. I wanted to make sure that the foreign-libs entry I added would let users write code that was compatible with foreign-libs and also with shadow-cljs, and cljsjs was rejecting my foreign-libs entry

Sam Ritchie18:06:25

your line should absolutely work with shadow-cljs (duh), and I think I figured out how to get past my problem in cljsjs...


yeah you can just setup foreign-libs to that the above require works with regular CLJS. can't remember how though.