I installed the empty meteor project by the tutorial and the NPM displays 2 high vulnerabilities. Is it dangerous? IS it possible to solve this problem? THX.
meteor npm audit fix
can normally fix it if new versions of problematic packages are known
If it cannot automatically fix, check the issue with meteor npm audit
From there you can check if the vulnerability is a huge deal. Sometimes, the issue is with dev dependency packages so it shouldn’t be a big deal
Thank you very much @rjdavid @alawi for the fast answer. In empty project it works, I will try it on real project.
…and maybe another question. When I will build the meteor node app, always is missing reify package. In production I need to always put npm install in server folder. I’m doing something wrong, or this is normal way of deployment?
Thx a lot.
When deploying you do need to run npm install
in the server
folder. You can learn more about how to deploy at Deployment and Monitoring | Meteor Guide.
Neither updating elliptic
, nor updating the dependants to the latest version does not fix it for me. Anyone git it fixed interim until the new meteor-node-stubs
is published?
meteor-node-stubs@1.0.1 was published now.
On Meteor 1.10.3 the skeletons will be updated as well to use this version.
… but why? If I build the app, and the result is completed builded app in one tar file, why the packages are missing and I need to run npm install again on server? Thx.
Any native dependencies your app uses will likely have to be rebuilt on the server, and Meteor uses an install script run during npm install
to rebuild them. Though I’ve also wondered why some npm dependencies are not part of the bundle.
Also, the correct way to install in production is
npm ci --only=production
(if npm is version 6)
That is good when installing the dependencies before the app is built, but when installing them in a built app at programs/server
you have to use npm install
since Meteor doesn’t put a package-lock.json file in the bundle.
Do you happen to know if there is a reason for this? This can cause a headache for those discrepancies and cases wherein package authors did a breaking change but only adjusted the patch or minor version of the package.
I do not know if there is a reason. The number of packages installed this way is limited and I don’t remember Meteor having an issue with it in the past. I think we should look into including these dependencies in the bundle to avoid having to install them when deploying, though it could complicate how we rebuild native dependencies. Keeping it as is and adding the package-lock.json would probably be simpler.
@zodern @rjdavid I think, when I will build the production app into tar archive, NONE or ALL dependencies MUST be inside the package. I dont understand, why part of the packages are included and another part not.
But most important result for me is, that this is not my mistake, but It’s standard meteor behavior.
Thank you very much for all answers