New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In some cases, meteor build doesn't include .bin
symlinks
#8136
Comments
Note: anyone encountering this due to upgrading |
Adding this to the 1.4.3 milestone, but I will port the fix to previous Meteor versions as necessary. |
@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 |
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 |
@ffxsam Only if you're depending on the Meteor |
Yep, I am indeed. I figured that was the case. |
@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 |
@benjamn |
@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
|
@abernix I have confirmed that |
I can confirm that the beta1 of 1.4.3 doesn't solve the problem for me! Here's the log:
|
Ok, I followed the earlier suggestion and installing the older bcrypt package solved the problem for me: meteor npm install --save bcrypt@0.8.7 But the beta1 doesn't solve it, so more research needs to be done. |
@a4xrbj1 Is this happening on a Galaxy deployment? I'd need you to break your setup again to research it further. While it's still broken, what is the output from the following:
|
I got the same problem with a newer bcrypt package and the current meteor release Meteor 1.4.2.3 on galaxy (local builds fine). using an older version worked for me: To reproduce this: Make a new meteor app, use accounts-password with bcrypt and save the binary npm package. Ensure it has a version > 0.8.7. Then deploy to galaxy and see it crash. |
In case it helps anyone else reading this, we had storybook installed which in turn depended on bcrypt 1.0.0 way down the tree. Broke galaxy deployments. :-( |
@chmac Isn't your storybook package in the |
@ffxsam I guess it probably should have been |
I used meteor npm install --save bcrypt@0.8.7 to solve this problem, which worked initially but has now stopped working for no apparent reason. Deployment using mupx used to be straightforward, not it's fraught with uncertainty. |
Unfortunately the fix for this (released in 1.4.2.5) turned out to have some issues. 1.4.2.6 fixes them! |
Thanks for the reply. I have avoided going beyond 1.4.0.1 as I encountered open file issues and wasn't able to increase ulimit -n above 4096. Will this work in 1.4.2.6? |
@mbateman If you can't increase your ulimit, you might want to set the
This increases CPU usage (because of the polling) but greatly decreases the open file count. |
Looks like initial issue was fixed, when NPM dependencies of dependent packages is not loaded. Please see issue here.
|
|
@benjamn thank you for quick response. Yes meteor version was $ meteor npm version
{ 'Meteor-Files': '1.7.9',
npm: '4.1.2',
ares: '1.10.1-DEV',
http_parser: '2.7.0',
icu: '56.1',
modules: '46',
node: '4.7.3',
openssl: '1.0.2k',
uv: '1.9.1',
v8: '4.5.103.43',
zlib: '1.2.8' } After update to $ meteor npm version
{ 'Meteor-Files': '1.7.9',
npm: '3.10.9',
ares: '1.10.1-DEV',
http_parser: '2.7.0',
icu: '56.1',
modules: '46',
node: '4.7.3',
openssl: '1.0.2k',
uv: '1.9.1',
v8: '4.5.103.43',
zlib: '1.2.8' } After removing $ meteor
[[[[[ ~/Sites/ostrio:files-demo/demo ]]]]]
=> Started proxy.
=> Started MongoDB.
ostrio:files: updating npm dependencies -- fs-extra, request, throttle, file-type...
/Users/drdimitru/.meteor/packages/meteor-tool/.1.4.2_7.1krbw9w++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:190
throw error;
^
Error: ENOENT: no such file or directory, rename '.npm/package-new-ssatz3' -> '.npm/package'
at Error (native)
at Object.fs.renameSync (fs.js:681:18)
at Object.wrapper [as rename] (/tools/fs/files.js:1535:35)
at Object.files.renameDirAlmostAtomically (/tools/fs/files.js:974:9) |
@benjamn removing everything in |
Thank you @benjamn for quick help. |
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 (egbcrypt@1.0.0
) depends on a program (egnode-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 fulldiff -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 ranmeteor 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 frombuilt/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 runnpm rebuild
in the produced tarball (as Galaxy does).The text was updated successfully, but these errors were encountered: