In some cases, meteor build doesn't include `.bin` symlinks

[glasser]

I've seen that in some cases, meteor build doesn't include .bin symlinks from npm modules in the app directory. This can break Galaxy when it rebuilds the app, if a package that needs to be rebuilt (eg bcrypt@1.0.0) depends on a program (eg node-pre-gyp) being on the PATH.

I've actually gone and done this experiment: in an empty directory, run meteor --release 1.4.2.3 create source && cd source && meteor npm install bcrypt && meteor build --directory ../built, then tried it again including --save in the bcrypt. I saved a full diff -ruN of the directories (both source and built). (Note that in order to keep references to absolute paths in generated files constant, each "source" directory was under /tmp/experiment when I ran meteor build; I then moved them elsewhere for the diff.)

The output of the diff: https://gist.github.com/glasser/98826a5fbf5d63f0f265acf167009bd6

You can see that when I pass --save, the symlinks are missing from built/bundle/programs/server/npm/node_modules/.bin.

The only other differences are the missing bcrypt line in package.json (this is basically the definition of not passing --save), a missing _requiredBy line in bcrypt's package.json (similar), and a note in node_modules/bcrypt/build/config.gypi (in both source and built) noting that it was saved.

I'm not sure why this causes the meteor build process to drop the .bin symlinks, but it does, and this breaks the ability to run npm rebuild in the produced tarball (as Galaxy does).

[glasser]

Note: anyone encountering this due to upgrading bcrypt specifically can work around this with meteor npm install --save bcrypt@0.8.7 — there's no new functionality in 1.0.0, just a build system change that conflicts here. (Well, there's a new Promise-based API that accounts-password does not use.)

[benjamn]

Adding this to the 1.4.3 milestone, but I will port the fix to previous Meteor versions as necessary.

[benjamn]

@glasser when you get a chance, please test this with

meteor create --release 1.4.3-beta.1 bin-links-test
cd bin-links-test
meteor npm install --save bcrypt
meteor npm install --save-dev mocha
ls -al node_modules/.bin
meteor build ../bin-links-build
cd ../bin-links-build
tar xf bin-links-test.tgz
cd bundle/programs/server
ls -al npm/node_modules/.bin
meteor npm install

The final ls -al should show a symlink for node-pre-gyp but not for mocha.

[ffxsam]

Hey Ben,

Thanks for checking this out! Quick Q: is the server-side warning about "Meteor is using a JavaScript implementation of bcrypt, use npm, etc" normal? In other words, will everyone see that out of the box until they run meteor npm i --save bcrypt?

[benjamn]

@ffxsam Only if you're depending on the Meteor bcrypt package, which probably means you're using accounts-password.

[ffxsam]

Yep, I am indeed. I figured that was the case.

[glasser]

@benjamn I verified that your steps show the symlinks, and also that the app can be successfully deployed to Galaxy without a rebuild failure.

(Note: I tend to use meteor build --directory when doing things like this!)

[ffxsam]

@benjamn 🍻

[abernix]

@vsivsi I had originally missed this issue, but I agree that this is likely the issue you are encountering that you documented in #7568 (comment).

Do you mind testing by trying 1.4.3-beta.1? It would be nice to confirm since you received a few up-votes on that comment:

meteor update --release 1.4.3-beta.1