If I install a package to the global node repository, will it override the dev_bundle version?
Do node-gyp pre-requisites need to be installed in the dev_bundle repository to make the dev_bundle version of node-gyp work? Maybe this is an exception to the overall guidance.
While i experienced the same issue. The only way i went around the problem was by uninstalling meteor and re-installing with a fresh download. It resolved all the problems. However i can understand that people are having issues updating existing projects that are based on the older build of meteor.
My suggestion is: use meteor remove … or locate the package file inside the .meteor folder and comment out the offending library. Thereafter you should be able to re-add it later once the update completes.
Hope this helps (worked for me on Windows 10 x64)
Edit: Unfortunately this did not work with all apps and i ran into an issue when a package had a dependency on fourseven:scss … Will keep everyone posted if i find a solution.
@brucejo I thought that was the “norm” when installing npm packages for Meteor (https://guide.meteor.com/using-npm-packages.html#installing-npm) That is the only reason I did it that way. I have only a high level understanding on how Meteor works (only 3 month experience) with not much npm experience and so I don’t think I’ll be able to shed much light on this subject other than what worked for me.
@aaronkenz Yes, it is the norm for project packages to do meteor install.
But node-gyp is a tool used by the build system and needs to be installed globally (e.g. -g). Installing globally into the dev_bundle should be considered very carefully.
Essentially, you altered the shipped dev_bundle by doing a -g install. But like I said above, I do not know if that is the right thing to do for the node-gyp prerequisites or not.
same exact problem with the same exact dependency… but on windows. So you did not remove the package name from the package.json file in .meteor you removed it via command prompt?
I feel that adding and removing these packages manually via terminal is too cumbersome because you might have many of these packages breaking. Since this whole round-trip might annoy some people around here. I dug into the problem a bit further and it is indeed related to the chaining of the dependencies.
In a nutshell if you add a dependency that is crashing during install to the chain before a given package requires it. You resolve the issue.
So for instance:
if materialize:materialize makes use of fourseven:scss and the latter crashes during installation.
Go to packages.json (in .meteor folder)
Put in the crashing dependency (fourseven:scss) in a line preceding the package being installed (materialize:materialize)
Tnx Mrw34, yes, i found out in the end the issue was the compiler. I had to run the compilation/installation as sudo since some permissions issues was involved. Now I have a build-system that works on centos6.5 and manage to upgrade all my projects.
I tried the above but nothing worked for me so I created a new project and I copied all the code, db and config files to the new build project that is all ready created at 1.4… version.
create a backup of the project
create a new temp project “meteor create NewProj”
delete all garbage files like main.html, main.js
copy the following directories and file from the old porject to the NewProj
a. all the directories except .meteor
b. .meteor\local\db folder
c. .meteor\packages file
Verify that all other important file are copyed (acording to your project structure)
run meteor… it will rebuild the project and will download all the packages (from the .meteor\packages file)
If it works, delete the old one (you have a backup) and rename the NewProj to the old one.