Package shouldn't need a binary build, but it does? Why?

help
1

I’ve been publishing early versions of rocket:module and Meteor gives me the familiar message:

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 rocket:module@0.1.1

For more information on binary ABIs and consistent builds, see:
  https://github.com/meteor/meteor/wiki/Build-Machines

but I don’t believe I have any NPM dependencies in rocket:module that are binary. I’ve moved the binary NPM libraries to rocket:webpack under the impression that only that package needs to be binary build for specific architecture when I update that package, so that way I don’t have to binary rocket:module every time I update some JavaScript.

Do I have the right impression about being able to separate the binary parts of a package into another package?

2

I read somewhere (I don’t remember where) that it was a strategy for some of the core packages to move binary NPM dependencies into a separate package to avoid having to publish binary builds each time that only JavaScript is updated.

I made an issue for it on GitHub: https://github.com/meteor/meteor/issues/4493

It’d be super inredibly awesome if build plugins inside of isopacks didn’t also contain the node_modules of their dependencies. :smiley:

3

publish-for-arch is the worst thing ever. I think that the build system should run npm install when an app is getting deployed, not when it’s getting bundled…

1 Like