What's happening to `meteor publish-for-arch` in Meteor 1.4.1

announce
1

If you’re an author of a Meteor package that has binary npm dependencies, you will no doubt be familiar with what happens when you run meteor publish:

Published benjamn:binary-package@0.0.16.
                                              
You're not done publishing yet! This package contains binary code and must be built on all of Meteor's architectures, including this machine's architecture.
                                              
You can access Meteor provided build machines, pre-configured to support older versions of MacOS and Linux, by running:
  meteor admin get-machine os.osx.x86_64      
  meteor admin get-machine os.linux.x86_64    
  meteor admin get-machine os.linux.x86_32    
  meteor admin get-machine os.windows.x86_32  
                                              
On each machine, run:                         
                                              
  meteor publish-for-arch benjamn:binary-package@0.0.16
                                              
For more information on binary ABIs and consistent builds, see:
  https://github.com/meteor/meteor/wiki/Build-Machines

To make matters worse, now that Meteor 1.4 is available, if you really want to ensure that everyone can install your package without having to recompile it, you have to repeat this process using Meteor 1.4 as well as Meteor 1.3, because binary packages built with Node 4 are not compatible with Node 0.10.x. In fact, since Meteor 1.4.1 includes Node 4.5.0, which is a minor update to Node 4.4.7, you would technically have to publish your package using Meteor 1.3, Meteor 1.4, and Meteor 1.4.1, on four different architectures, which means running meteor publish-for-arch at least twelve times for every new version of your package!

We’re not going to stop releasing new versions of Meteor with new versions of Node, so this situation was only going to get worse over time, unless we made some changes to the way packages are published.

First we eliminated all binary dependencies from Meteor core packages (here and here), so that the experience of installing packages like accounts-password, npm-bcrypt, and oauth-encryption will no longer be affected by any of the issues we’re discussing here. Simple but effective.

The second part of the solution was a bit more radical: when you publish a package using Meteor 1.4.1, the meteor publish-for-arch command will no longer be mandatory. Instead, your package will be published the same way packages without binary dependencies are published, and it will be the responsibility of each developer who installs your package to have the necessary compiler toolchain so that Meteor can automatically rebuild the package’s dependencies for the target architecture. Packages published in this way will work for developers using Meteor versions as old as 1.3.3, provided they’ve installed a working compiler toolchain.

Note to package authors: before publishing an existing package with Meteor 1.4.1, we recommend bumping its version number by at least a minor version, so that you’ll still have room to publish your package for older versions of Meteor if you have to. Just run meteor --release <older Meteor version> publish, and all the old meteor publish-for-arch mechanics will still work.

This is great news for package authors, but we realize there may be some package consumers who previously benefitted from meteor publish-for-arch who will now need to install a compiler toolchain, and may need help debugging that installation. Of course, if you’re not using any npm packages that contain binary .node modules, you won’t need a compiler toolchain.

Specifically, if you are attempting to meteor add some:package, and you encounter errors that mention npm rebuild, node-gyp, or node-pre-gyp, possible solutions include

  1. Installing and/or debugging your compiler toolchain, after consulting the 1.4 upgrade guide. If that documentation is inadequate, please open an issue or (better yet) submit a pull request.
  2. Running meteor npm install the-npm-package in your application directory. If that command fails in the same way, then the npm package may have a bug, and you should open an issue with the npm package, not the Meteor package that uses it.
  3. If you think the problem lies in the Meteor tool itself, open an issue with a clear reproduction, following all the usual steps so that we can help you diagnose and solve your problem.

Please note that complaining to the author of the Meteor package is not one of the solutions listed here! Helping you install a compiler toolchain is ultimately the responsibility of the Meteor team, not the responsibility of any Meteor package author, and package authors should feel free to close any such issues, pointing to this post and the relevant documentation, which will continue to improve as necessary. Meteor will do everything in our power to make this process as smooth as possible for everyone in the community.

4 Likes