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
@juhoteperi I think you are the most likely to know this - I have now updated the packages for vega, vega-lite, vega-embed and vega-tooltip. These are all versions in support of the final release 3 of vega and release 2 of vega-lite. Newer are now dev rc versions.
@miikka Could you perhaps know the answers to these? Thanks.
@juhoteperi before I commit, should I remove the target directories? Second, should I make four separate commits or all updates in one?
@miikka Dang, these were the actual questions...
@jsa-aerial Yes, you should remove the target directories. And probably better for clarity to have separate commits.
@miikka Thanks for the answers! I will remove the target dirs and make the separate commits. Should these also be separate pull requests or a single with the multiple commits?
I guess a single PR is fine.
@miikka I think there is something I do not understand about what the deps in the build.boot files mean. I am getting the error org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact cljsjs:vega:jar:3.3.1-0 in clojars (, but that's because this 'commit' is supposed to build that (and the other new version) jars and deploy them there. So, I must have a kind of chicken/egg confusion about what the deps in the build files mean. I'm not a boot guy, so that may be a contributing factor...
@miikka I have a guess as to what this problem is. If there are dependencies as: vega <- vega-lite, vega <- vega-embed, vega-lite <- vega-embed, and vega <- vega-tooltip, then it looks like the integration tests require that vega (3.3.1) needs to be literally deployed to clojars before any of the rest have a chance to pass, and that vega-lite also needs to be deployed to clojars before vega-embed has any chance to pass. Such deployment appears to happen on successful PR resolution. So, it looks like these cannot be done with a single PR. There needs to be one for vega first, then one for vega-lite next, then one for vega-embed after that. While vega-tooltip could also be done after vega, probably best as a final PR. Does this make sense?
Yes, you're right, sounds good. I didn't realize that there's the chain of dependencies for the libraries.
@miikka OK, it looks like we are on the right track - vega PR passed all checks. Does a 'blessed' maintainer need to now close the pull or do I close it and then a blessed maintainer merges and that is when clojars will be updated. I don't want to start adding vega-lite until I know this vega is totally completed as it will fail. Thanks for any info - thanks for patience - this is the first time I'm doing this...
Do not close it, a maintainer will merge it. I don’t have time today anymore, but I’ll check it tomorrow.
✔️ Thanks!
@euccastro has left the channel