Custom Meteor release

mitar · November 21, 2015, 8:38am

Is there any more information how to create our own custom Meteor release? We would like to create a custom fork of Meteor with additional targets (from what I understand, that is necessary to support them). How does one make it so that if somebody clones our app (projects) and runs meteor that our Meteor release will be picked up to run the app?

cc @awatson1978, help!

shcherbin · November 21, 2015, 8:42am

Maybe it will help Meteor, as io story helped node

awatson1978 · November 21, 2015, 10:24pm

It’s actually pretty simple if you understand a) that the publish-release command requires a .json file as a parameter, and b) what that file looks like. That was definitely the biggest hurdle in getting started, because it’s pretty much not documented anywhere.

Release Manifest
Here’s an example of what it the release manifest should look like:

github.com

awatson1978/ckcc/blob/master/clinical.meteor.rc6.json

{
  "track":"clinical:METEOR",
  "version":"1.1.3-rc6",
  "recommended": false,
  "tool": "clinical:meteor-tool@1.1.3_1",
  "description": "Clinical Meteor, RC6",
  "packages": {
    "accounts-base":"1.2.0",
    "accounts-password":"1.1.1",
    "aldeed:autoform":"5.5.1",
    "aldeed:collection2":"2.5.0",
    "aldeed:http":"0.2.2",
    "aldeed:simple-schema":"1.3.3",
    "aldeed:template-extension":"3.4.3",
    "autopublish":"1.0.3",
    "autoupdate":"1.2.1",
    "awatson1978:fonts-helveticas":"1.0.4",
    "awsp:handsontable":"0.11.0",
    "base64":"1.0.3",
    "binary-heap":"1.0.3",

This file has been truncated. show original

Honestly, I’m a little surprised there’s not a more active marketplace/trading of these manifest files. Maybe 2016 will be the year for that, and we’ll get back to having curated distros for industry verticals.

Publication/Usage
But I digress. The idea is that we simply want to run something like the following command:

meteor publish-release clinical.meteor.rc6.json

Which will then allow us to run this:

meteor run --release clinical:METEOR@1.1.3-rc6

Identifying Packages to Include
To get things published isn’t particularly difficult. Just requires a bit of busy work. In particular, keep in mind the following points:

Every package in the release has to be published and on Atmosphere.
The .meteor/versions file of an app is a particularly good place for finding all the necessary packages and versions that should go into the release.

After that, it’s a matter of figuring out what you’re willing to support, what you want to include, etc. Here is a partial Venn Diagram of what the Clinical Release is currently working on; and should give you a general idea of how we’re going about the decision making process of what gets included.

Meteor Tool
If you need to extend the meteor tool or the command line, you’ll need to create and publish your own meteor-tool package. Ronen’s documentation is the best out there for this process:

http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/

It’s easy to get a meteor helloworld command working, but after that, I felt it was easier to just create a separate node app to test out commands. Which is how StarryNight came about. It’s something of a staging ground and scratchpad for commands before trying to put them into a version of the meteor-tool.

StarryNight
Speaking of which, I created a small utility for creating the release manifest, which is available in StarryNight.

cd myapp
starrynight generate-release-json

mitar · November 21, 2015, 10:48pm

But that was hard because Meteor was picking node_modules directory. Luckily it does not do that anymore.

OK, is there a way to get that JSON file for official Meteor release? Why is that not in the repository? Or is it? I think it would be a great place to start. Especially because I am planing to more or less follow the official release, just add more targets.

Also, is it possible to “pin” a project to a release? So that it is not necessary to run meteor run --release clinical:METEOR@1.1.3-rc6 but one could just run meteor, but because the project was created with a custom release, it would work? Would changing .meteor/release file to clinical:METEOR@1.1.3-rc6 fix that?

How does api.versionsFrom then work? Does it base it of that release? So would api.versionsFrom('1.1.3-rc6') be equal to api.versionsFrom('clinical:METEOR@1.1.3-rc6')? Does that even work?

mitar · November 21, 2015, 10:49pm

Oh, and that means that all packages have to be public? So both releases and packages have to be public? Hmm.

awatson1978 · November 21, 2015, 11:43pm

Great questions. I’d be interested to see the manifest file also. Hopefully, somebody from MDG can provide a link?

From my preliminary tests, yes and yes. To the point that there are some mix-and-matching rules which I don’t fully understand. One thing I know is that I’ve had to publish all the packages in the release with the previous Meteor build.

That is, a release can’t be published if it has packages with api.versionsFrom() that specify a later Meteor build. We had some packages published with Meteor 1.2 that had the ecmascript package automatically installed, and that broke our clinical:METEOR@1.1.3-rc6 release. So we had to go back to those packages and publish them with basic Meteor 1.1.3.

mitar · November 22, 2015, 12:11am

I opened a ticket: https://github.com/meteor/meteor/issues/5688

sashko · November 22, 2015, 5:56pm

Here’s the command (you can show releases, and not just packages!)

meteor show --ejson METEOR@1.2.1

mitar · November 23, 2015, 2:34am

And this is the command to make a JSON file and publish a release. Great!