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

announce
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
21

Sorry if this is stupid question, but since I have read that it will be easier to update node versions with meteor now will it be possible to deploy node 6 with meteor 1.4 or will we have to wait for new a version of meteor that supports it?

22

It looks like it’s a 1.5 feat:

23

More specifically, further down in that article Ben states,

Our current vision for Meteor 1.5 is that you will be able to use whatever (relatively recent) version of Node you like: #7072

In all likelihood, Meteor 1.5 will be released before Node v6 is ready for production use, so most Meteor developers will want to keep using Node v4 with Meteor 1.5 for a few months at least. When Node v6 is ready, the transition will be straightforward.

Note that the reason for the delay is primarily because Node V6 isn’t really production ready, not an internal one in Meteor.

If you’re developing now for something that isn’t going to be deployed until the October timeframe, you might consider using the Node 6 PR’s branch of the Meteor repository to do your development. I encountered the same issue with needing Node 4 in order to utilize a particular NPM module 2 months ago. I used the the “Slow Start (for Developers” approach to run Meteor from the bleeding edge code and, remarkably, I never bled. The Node 4 support of the in-development 1.4 code was stable for my purposes from day one about 7 or 8 weeks ago. If you’re on Linux (wouldn’t try this on Windows), it’s worth a thought.

2 Likes
24

@rlivingston Yup, I’m bypassing meteor test. It comes with certain hassles, but unit tests are much faster. It’s a tradeoff.

1 Like
25

Ok, we install the build tools and then what? I’ve updated to the latest npm and node version but it still gives an error when trying to update.

1 Like