Navigation Menu

Skip to content
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

NPM and Node versions don't follow project's Meteor release #7338

rhettlivingston opened this issue Jul 1, 2016 · 6 comments

NPM and Node versions don't follow project's Meteor release #7338

rhettlivingston opened this issue Jul 1, 2016 · 6 comments


Copy link

rhettlivingston commented Jul 1, 2016

I'm using multiple versions of Meteor including 1.3.0,, and 1.4-beta.6 for this example. My development system is on Ubuntu 16.04, so this isn't a Windows problem.

I've read time and time again that a big advantage of using 'meteor npm' instead of 'npm' in a project is assuring that you are using the right version. So, I do.

While debugging an issue in the meteor/todos configuration, I realized that a component of the problem I was battling was that I was running NPM 3.9.6 when using 'meteor npm' in the meteor/todos project which is a meteor v1.3.0 project (as indicated by .meteor/release).

I then blew away my ~/.meteor directory to clear out all of my meteor versions and get back to ground zero and downloaded a clean copy of meteor/todos. When I ran 'meteor npm install' in the todos, it correctly used Node 0.10.45 and NPM 2.15.1.

Then I downloaded a clean copy of a project that I have that is based on and switched to that directory. When I ran 'meteor npm install' in that directory, it again used Node 0.10.45 and NPM 2.15.1. However, it should be using NPM 3.9.6.

I ran 'meteor' in the app's directory and it went through downloading the versions of packages.

After that, I got the following

rhett@dreamshot:~/oob/meteors/oob$ meteor --version
rhett@dreamshot:~/oob/meteors/oob$ meteor npm -v
rhett@dreamshot:~/oob/meteors/oob$ meteor node -v
rhett@dreamshot:~/oob/meteors/oob$ cd ../todos
rhett@dreamshot:~/oob/meteors/todos$ meteor --version
Meteor 1.3                                    
rhett@dreamshot:~/oob/meteors/todos$ meteor npm -v
rhett@dreamshot:~/oob/meteors/todos$ meteor node -v

I then switched to a clean project that is set to release 1.4-beta.6 and in fact has a NPM package that has a hard dependency on Node 4. Guess what.

rhett@dreamshot:~/oob1.4/meteors/oob$ meteor --version
Meteor 1.4-beta.6                             
rhett@dreamshot:~/oob1.4/meteors/oob$ meteor npm -v
rhett@dreamshot:~/oob1.4/meteors/oob$ meteor node -v

So, that project doesn't work any more.

Does meteor not truly support the development of multiple projects on the same system with different versions of meteor?

I know how to force an npm switch (meteor npm install -g npm@3.9.6), but how can I force a Node version switch?

@benjamn benjamn added this to the Release 1.4 milestone Jul 1, 2016
@benjamn benjamn self-assigned this Jul 1, 2016
Copy link

Upgrading to 1.4-beta.7 still gives me Node v0.10.45

Copy link
Contributor Author

rhettlivingston commented Jul 2, 2016

So, updated to beta.7 and my link still points to the bundle. So meteor npm version still reports node 0.10.45. But, 'meteor' apparently switches to the beta.7 bundle under the hood (and prints out that path to indicate that is the case).

I reread Ben's post at and manually changed the link using

rhett@dreamshot:~/.meteor$ ln -sf packages/meteor-tool/1.4.0-beta.7/mt-os.linux.x86_64/meteor ./

Then, when I ran meteor npm version in the beta project's directory, it of course reported node 4.4.7. Very good.

Even better, when I switched to the todos directory, I got the following result.

rhett@dreamshot:~/oob/meteors/todos$ meteor npm version
{ npm: '2.14.22',
  ares: '1.9.0-DEV',
  http_parser: '1.2',
  modules: '11',
  node: '0.10.43',
  openssl: '1.0.1s',
  uv: '0.10.36',
  v8: '',
  zlib: '1.2.8' }

AWESOME!!! It detected that I was in a 1.3.0 project and switched!!!

But, now, it isn't pointed to code that knows how to switch back when I go back to the other directory.

So, this shows promise for helping the problem going forward... but I think it really badly needs to be fixed going backward. Also, it isn't a complete fix going forward.

I am a multi-tasker and, as of a couple of months ago, we started entering a world where different versions of npm and node are going to be commonplace. It is not unusual for me to have multiple terminals open working with multiple apps that run different versions of meteor. I've had as many as 4 like that.

This ~/.meteor/meteor link is now a very weak link in that scheme. Even if we get it to switch with every invocation of meteor or meteor npm in a different app's directory, that only fixes the one at a time approach to development. It can't support multiple apps simultaneously running with different versions of node and npm. It can't be multiple things at once.

As NPM and Node switching at will, even independently of the meteor version, is the route we're moving too, it seems that the link has to go and the sooner, the better.

In the meantime, I think that as a temporary workaround I'm going to have to write a script that looks into my .meteor/release directory and changes this link before running /usr/local/bin/meteor. And I'll have to combine that with always remaining conscious of what, if anything, is already running meteor before I invoke my script... 😦

Brainstorming here...
I'm wondering if there might be some way to change the /usr/local/bin/meteor script to fake this out at a higher level. If every invocation of meteor thought that it was running against its own ~/.meteor that had its own link to its correct bundles within it, multitasking might even work. The original ~/.meteor could remain unchanged behind the scenes. The gotcha might then be if someone ran meteor update --release xxxx. It looks like having to look into the sqllite database to identify what bundle to use is a weak link in this. Would be better if there were a nice simple text file with that info.

Copy link
Contributor Author

Using sqlite3 and jq, I created a bash script (based off of meteor code) that corrects the symlink before invoking meteor. It is helping greatly with switching between 1.3, and 1.4-beta.7 project directories though I haven't tried running with multiple fake warehouse directories yet to actually attempt simultaneous execution of different versions. Maybe later.

It is at if anyone is interested in a quick partial workaround.

Copy link

abernix commented Jul 5, 2016

I'm not 100% certain at the moment, but it's likely that the fix that @benjamn made in f38725e will not work properly until Meteor 1.4 is a recommended release, due to this code that updates the symlink. Most likely this is done on purpose to ensure that the main meteor-tool symlink only points to a stable release.

Copy link

benjamn commented Jul 5, 2016

@abernix this is correct in theory, though I'm somewhat concerned we may not always update that symlink, and the meteor.bat script works totally differently on Windows. It's definitely worth verifying that things are going to work as expected once 1.4 is a recommended release. If we end up changing how it works, that might be a good opportunity to make it work better for prereleases, too.

Copy link
Contributor Author

That thumbs up is for the automatic symlink update with prereleases! When @benjamn commented about that in the forums last week, I was very happy. What is the beta program testing if they aren't always running with the right NPM and Node combination on an upgrade where Node is the point.

Someone coming from Meteor 1.3 to the 1.4 beta program will likely do their NPM install using both the old NPM and Node. That can be very misleading.

I think problems with this, mostly with development environment stuff, are more common than we might think but so hard to pin down that we think of them as environment flakiness. If you're running, download any sample app including todos, go to it and run 'meteor npm install', you'll run the install with NPM 3.9.6. There are things that then don't work right, especially in the arenas of lint tools and testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants