/ meteor Public
meteor publish-for-arch unnecessary in most cases
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
Currently, if you are a Meteor package author, and your package depends on an npm package that uses native modules, running
meteor publishwill prompt you to build and publish your package on Mac (64-bit), Linux (32-bit and 64-bit), and Windows (32-bit), using the
Though MDG provides free build machines via https://build.meteor.com and
meteor admin get-machine, it would be an overstatement to say that building packages on these machines (especially Windows) is easy or quick. To make matters worse, the upgrade to Node 4 in Meteor 1.4 imposes additional burdens for package authors who want their packages to work for Meteor 1.4 developers as well as pre-1.4 developers.
Fortunately, since Meteor 1.3.3, it has been technically possible to avoid running
meteor publish-for-arch, because Meteor 1.3.3+ has the ability to recompile binary npm dependencies found in Meteor packages. You could trigger this behavior by running
METEOR_FORCE_PORTABLE=1 meteor publishwhen you published your package, though that was never recommended, and is likely not documented anywhere (except in the code).
This pull request disables the pre-publish portability check, thereby deferring compilation to package installation time. This is similar to setting
METEOR_FORCE_PORTABLE=1by default. Automatic rebuilding requires the end-user developer to have a compiler toolchain installed on their development machine, whereas
meteor publish-for-archwas meant to avoid that requirement. However, having a basic compiler toolchain is already a soft prerequisite for using many packages from npm, and it's easier for the end-user developer to configure a toolchain once than it is for a package author to do that work four (or even eight) times, every time she publishes the package.
Once this is merged and released (likely in Meteor 1.4.1), it will still be possible to pre-build binary dependencies and publish them using
meteor publish-for-archif you really want to, either by specifying an older version of Meteor when you publish (e.g.,
meteor --release 1.4 publish) or by setting an environment variable:
METEOR_ALLOW_NON_PORTABLE=1 meteor publish.
We believe this change will reduce demand for https://build.meteor.com sufficiently that we may consider turning off the build farm. If you are a package author who uses the build farm, we would love to hear your thoughts on this change, especially if you think you would continue running
meteor publish-for-archafter you are no longer expected to do so.