Announcing Meteor 1.3.4(.1) and 1.4-beta.1

announce
1

If you’ve been trying to follow the recent history of Meteor releases since 1.3.3 was announced ten days ago, chances are you have some questions:

  • Why did we release 1.3.3.1?
  • Why did we then release 1.3.4 instead of 1.3.3.2?
  • What is the current recommended release?
  • When can I start using Meteor 1.4?

I will answer these questions below. If you have other questions, just ask!

Why did we release 1.3.3.1?

Meteor 1.3.3.1 was an immediate follow-up to 1.3.3, aimed at fixing bugs encountered predominately by Windows developers. Here is the complete list of changes.

The worst of the problems stemmed from the arbitrary 260-character limit imposed by Windows cmd.exe and PowerShell on the maximum length of file system paths. Because npm is all too happy to nest node_modules directories to unlimited depths, it’s only a matter of time before a large npm-based application hits these limits. Windows developers have noted this frustration before, and it seems Microsoft has no plans to address it.

The path length limit may be frustrating, but one can usually hoist npm packages higher in the dependency tree to work around the nesting limitations, and that’s exactly what Meteor 1.3.3.1 did for the npm dependencies of the babel-compiler Meteor package.

Why did we then release 1.3.4 instead of 1.3.3.2?

While reorganizing node_modules directories seemed like an appropriate stop-gap fix for a 1.3.3.1 follow-up release, the underlying problem calls for a more general solution.

In particular, if Meteor had been using npm@3 instead of npm@2.15.1, then all of its node_modules directories would be automatically flattened as much as possible, which is good news for all Meteor developers, but great news for Windows developers.

That said, upgrading the major version of npm used by Meteor is not a trivial change! I wanted to do it eight months ago, but we settled on shipping npm@2 with Meteor 1.3. Given the npm-related bugs in Metor 1.3.3, and our misgivings about the longevity of the solution provided by 1.3.3.1, we decided it was finally worth the effort and risk to switch to npm@3.9.6.

Now, because Meteor uses npm-shrinkwrap.json files for package npm dependencies, the structure of node_modules directories for Meteor packages should not change until those packages are republished, and the shrinkwrap files are rewritten. And because Meteor does not run npm install on your behalf for application node_modules, it’s up to you to decide when you want to reinstall your node_modules using Meteor 1.3.4 and npm@3.9.6. For these reasons, we do not anticipate any unwelcome breaks in backwards compatibility due to the npm upgrade, though it certainly seemed to warrant a 1.3.4 release, rather than a 1.3.3.2 release.

Since we were cutting yet another release, we took the opportunity to implement some significant IO performance improvements as well. Here is the complete list of changes in Meteor 1.3.4.

What is the current recommended release?

I would like to say that Meteor 1.3.4 was the final answer to everyone’s problems, but unfortunately forward progress always has risks. This seemingly innocent pull request included in Meteor 1.3.4 added a timeout to HTTP requests made by the meteor command-line tool, which broke meteor deploy for Galaxy developers whose uploads took longer than 30 seconds.

That problem was fixed in Meteor 1.3.4.1, and so now 1.3.4.1 is the version of Meteor that you’ll get when you meteor update.

When can I start using Meteor 1.4?

If you’re ready to start using Node 4.4.5 and Mongo 3.2, I’m happy to announce the latest beta release, which you can install by typing this command:

meteor update --release 1.4-beta.7

You can follow the developments (and report any problems) here.

Thanks for bearing with us!

36 Likes
2

As a primarily Windows based developer, I’ve been checking every week for news on a npm update. Thank you, thank you, thank you!

9 Likes
3

Will this release have implications on deployment, specifically meteor up? Can we already deploy with this if we want to?

2 Likes
4

I did not encounter any problems with mupx yet but still early

5

Can you please just do an auto-update?

I don’t really mind having an extra replica of meteor on my server or localhost to recompile/update my running app.

Some external “mimiMeteorUpdateController”… :slight_smile:

6

No, please don’t. People have valid reason to pending an update.

3 Likes
7

What’s the correct .babelrc to emulate what meteor does? I currently have

{
  "presets": [
    "es2015",
    "react",
    "meteor"
  ]
}

where “meteor” refers to babel-preset-meteor. Is this correct?

The context of this question is that I’m running unit tests without using meteor test (see this post) and want mocha to compile js in the same way as meteor when I run mocha ./tests/unit-tests --compilers js:babel-register.

8

Hi @rdickert! Looking forward to catching up at Meteor Camp NYC in a few days :slight_smile:

I believe the closest you can come without using meteor-babel/register (which is similar to babel-register, though the setup is somewhat annoying) would be to put the following in your .babelrc file:

{
  "presets": ["meteor", "react"],
  "plugins": ["transform-es2015-modules-commonjs"]
}

This works because the babel-preset-meteor package has everything that babel-preset-es2015 has, except for the CommonJS modules transform.

The vanilla babel-plugin-transform-es2015-modules-commonjs will force your modules to declare themselves "use strict", which may be a problem if your Meteor code assigns to global variables.

Note that this .babelrc won’t allow you to use nested import declarations. For that you should probably use meteor-babel/register.

1 Like
9

Also, for what it’s worth, meteor test will be much faster in Meteor 1.4, thanks to this commit.

7 Likes
10

@benjamn me too!

Thanks for the suggestion. I’ve tried that .babelrc setup and it seems good. There’s one other quirk I came across, which is that

import NavBar from '/imports/ui/components/NavBar';

works in meteor but not when the same code is imported by a test. A relative path works for both:

import NavBar from '../components/NavBar';

I’ll check out meteor-babel/register if I have the time, but this is still good. On the faster reload for 1.4, it probably won’t change my approach for unit tests, but it sounds like an awesome improvement for integration tests and general development. Great work here – really happy where this is going. :slight_smile:

1 Like
11

I’m still getting bcrypt errors @benjamn . I know you already updated some bcrypt dependencies but it doesn’t look like this fixed the issue for me on Windows.

12

@AndreasGalster The npm-bcrypt package was last published using Meteor 1.3.4.1, so in order to use it with Meteor 1.4 you’re going to need a compiler toolchain.

Please follow the instructions for installing the Windows build tools here, specifically

  • On Windows:

You shouldn’t need to install Python (since it’s included in the Windows dev_bundle) or set any variables (since meteor npm does that for you).

It would be nice if this wasn’t necessary, but once you’ve installed a working compiler toolchain, you shouldn’t have to think about it again.

13

So does this mean we should just simply follow your instructions if we want to use beta builds or once out of beta we will have the right dependencies to get it running even without setting that up?

14

You should follow the instructions regardless.

Once Meteor package authors whose packages contain binary npm dependencies start publishing their packages using Meteor 1.4, you won’t always need to have a compiler to use those packages with Meteor 1.4, but that won’t start happening until 1.4 is out, and in some cases may not happen for a long time after that, e.g. if the package author has abandoned the package and never publishes it again.

1 Like
15

It looks like running meteor npm XXX still returns node 0.10 on 1.4-beta.6

16

This is the reason why, but it’s not a great reason. I wonder if we should update the version that meteor npm and meteor node refer to whenever you successfully do meteor update --relase ..., even if the release is experimental.

2 Likes
17

That’d be cool, as long as it only updates it for that specific project. Have a lot of meteor projects with all sorts of different versions on my machine :slight_smile:

18

The way to fix it in the meantime is to update the ~/.meteor/meteor symbolic link:

% cd ~/.meteor
% ls -l meteor
lrwxr-xr-x  1 ben  staff  57 Jun 29 16:54 meteor@ -> packages/meteor-tool/1.4.0-beta.6/mt-os.osx.x86_64/meteor
% mv meteor old-meteor
% ln -s packages/meteor-tool/1.4.0-beta.6/mt-os.osx.x86_64/meteor ./
% meteor npm version
{ npm: '3.10.2',
  ares: '1.10.1-DEV',
  http_parser: '2.5.2',
  icu: '56.1',
  modules: '46',
  node: '4.4.7',
  openssl: '1.0.2h',
  uv: '1.8.0',
  v8: '4.5.103.36',
  zlib: '1.2.8' }

Note that you need to have done meteor update --release 1.4-beta.6 in order for the ~/.meteor/packages/meteor-tool/1.4.0-beta.6/ directory to exist.

19

I’m curious, I’ve seen a lot of people complaining about this, but I haven’t experienced it. The absolute import works fine in my tests. Perhaps it is because I currently only use unit tests? Or is it because I run my tests with Meteor using

 $meteor test --once --driver-package practicalmeteor:mocha

and perhaps others are bypassing Meteor?

20

That is the way I assumed it worked initially.

I updated to a beta with --release to test node 4.x with a project, even though I knew it was experimental, so I got quite confused by the node v. 0.10.

A question about the current solution to npm and node versions:

When 1.4 is released and node 4.x becomes the new default, is this scenario then possible?:

  • Update a project with meteor update to meteor 1.4 and node 4.x
  • Choose to downgrade again with meteor update --release 1.3.4.1.
  • End up with a broken meteor 1.3 and node 4.x combination