Hi all,
Has anybody had any success with publishing a track with a modified core package?
I followed Ronen’s excellent tutorial from 6 months ago, and have managed to publish a custom track (clinical:METEOR@1.0.4-rc18), and am able to register commands on the custom track. But there are a few core packages I’d like to hack on for the Clinical Meteor Track… notably mongo, minimongo, mongo-livedata, tinytest, reactive-dict, deprecated/d3, etc.
On line 802 of the commands-package.js, it says the following about the --from-checkout option:
// This is sort of a hidden option to just take your entire meteor checkout
// and make a release out of it. That’s what we do now (that’s what releases
// meant pre-0.90), and it is very convenient to do that here.
//
// If you have any unpublished packages at new versions in your checkout, this
// WILL PUBLISH THEM at specified versions. (If you have unpublished changes,
// including changes to build-time dependencies, but have not incremented the
// version number, this will use buildmessage to error and exit.)
//
// Without any modifications about forks and package names, this particular
// option is not very useful outside of MDG. Right now, to run this option on
// a non-MDG fork of meteor, someone would probably need to go through and
// change the package names to have proper prefixes, etc.
So I tried to give a prefix to all of the packages, with the idea that I’d try to just go ahead and publish 100+ packages in the clinical org namespace if I had to, and see if that’s what’s needed to publish a custom track. Doing that involves updating like 500 or maybe 1000 package references, which was a chore but fairly straight-forward. Not surprisingly, however, I eventually hit a wall. Refactoring the names within the packages themselves was pretty clear (albeit tedious); but there are random references to packages outside the package API, and that’s when everything became murky. If it’s not just the references inside the Package API that needs to be prefixed, then it becomes unclear what needs to be refactored.
It was really great to work with the meteor publish-release command though, and to give another try at creating a custom meteor track. That functionality seems really polished since 6 months ago, and close to being ready for general use. But package name collisions, API collisions, and package references in the tools seem to have gotten the best of me. In the end, I wasn’t able to just prefix all the packages and create a new track.
If anybody else has had any success with creating custom tracks, would love to hear about it or get some pointers on other things to try…