This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-01
Channels
- # beginners (59)
- # cider (3)
- # clara (4)
- # cljsjs (4)
- # clojure (144)
- # clojure-finland (2)
- # clojure-italy (10)
- # clojure-russia (2)
- # clojure-spec (7)
- # clojure-uk (53)
- # clojurescript (81)
- # cursive (30)
- # datomic (36)
- # defnpodcast (2)
- # editors (3)
- # emacs (4)
- # events (1)
- # fulcro (12)
- # off-topic (11)
- # onyx (14)
- # parinfer (2)
- # pedestal (12)
- # re-frame (3)
- # reagent (26)
- # shadow-cljs (81)
- # spacemacs (10)
- # sql (59)
- # uncomplicate (4)
- # yada (4)
Hi - I need four packages - vega (to 3.3.1), vega-lite (to 2.6.0), vega-embed (to 3.16.1), and vega-tooltip (to 0.12.0) to be updated (they already exist in older versions). If this is something someone already is doing, I'm much obliged! If not, I am trying to figure out how to do this. I'm handicapped by not being particularly knowledgeable in either JS packaging or CLJSJS packaging. I know about https://github.com/cljsjs/packages/wiki/Creating-Packages but those handicaps have me mostly scratching my head. So, a couple questions to start. If updating, do I still need to fork the cljsjs/packages repo? Seems like this is still required, but... Second, if updating is OK to just run http://jmmk.github.io/javascript-externs-generator/ on the new versions instead of taking the old extern files and trying to figure out how to update or even if they need to be updated? Thanks for any help!
Doesn't help I'm not a boot guy either...
So, to answer my own questions: Yes, you need to fork so that you can subsequently issue pull request. Second, yes the best approach is to always auto generate (in this case there were significant changes that really would not be easy to manual adjust).
Also, https://github.com/cljsjs/packages/wiki/Creating-Packages really needs to describe the boot aspects. In particular just issuing boot package
doesn't ever generate the jars - this despite all manner of output messaging claiming otherwise. boot package
appears to be just a sanity check that the build.boot at least behaves 'sensibly'. But to get the actual artifacts you need to issue boot package install target
. That will actually generate the jar which you can then test. I would highly recommend this be documented in the above link page