Please help test the latest 1.3.3 beta release!

announce
1

To update to the latest beta release of Meteor 1.3.3, simply run

meteor update --release 1.3.3-beta.2

in any Meteor application directory. If you encounter problems, please either file issues on GitHub or ask questions on the GitHub tracking issue.

Meteor 1.4 will follow very shortly after Meteor 1.3.3, with newer versions of Node and MongoDB, and relaxed package version constraints, all of which are already implemented, tested, and merely waiting to be released. You might ask, then: why even release Meteor 1.3.3, instead of jumping directly to Meteor 1.4? A few reasons:

  • Though Meteor 1.3.3 is a more conservative release than 1.4, it contains a number of noteworthy changes since 1.3.2.4, so we wanted to make sure users who aren’t ready for major updates to Node or Mongo can still get the improvements in 1.3.3.
  • It will be much easier to distinguish between Meteor-specific bugs and bugs related to the Node/Mongo upgrades if we have a recent version of Meteor that includes everything except those upgrades.
  • Updating to Meteor 1.3.3 before updating to Meteor 1.4 is a good way to make sure your app is fully up-to-date with the module system, testing, and Cordova changes introduced in 1.3, before you change another important variable in your stack.

Changes since Meteor 1.3.2.4.

Full announcement on GitHub.

17 Likes
2

Really excited about the .babelrc thing - it will be easy to add static class properties, which are quite popular in the React world!

8 Likes
3

import statements in application modules are no longer restricted to the top level, and may now appear inside conditional statements (e.g. if (Meteor.isServer) { import … }) or in nested scopes.

What is an application module? Does this mean anywhere in our app we can now conditionally use imports just like we were able to use requirejs conditionally to for example load a component/package when moving to a specific route?

4

Yes it does!

I’m not sure what restrictions “application module” implies - maybe it doesn’t work in packages? @benjamn maybe something to clarify.

2 Likes
5

Awesome change then! :smiley:

Just curious though: I don’t think that’s standard compliant, is it? Afaik the official import spec at this point doesn’t allow dynamic insertion (yet) which they’re planning to ship eventually though?

3 Likes
6

Compiler plugins can now import npm packages that are visible to their input files using inputFile.require(id)

Could we somehow get this also in minifier plugin?

7

please make a tutorial or a blog post about it.

1 Like
8

I think that in itself is a bad thing. I’d rather we keep things to the standard as possible with regards to imports. The only exception I would have to this rule is for jest.unmock('../somefile') which is used for ReactJS testing, but the API in itself is a “loader” much like import.

1 Like
9

I’m a bit confused as to where/how we file issues. In the thread posted above itself or by filing a new issue?

FlowRouter.route('/print-shops', {
  name: "print_shops",
  action: function(queryParams) {
    import './ui/views/landing-view.js';
    // require('./ui/views/landing-view.js');
    mwcLayout.render("landing-view", {"main": "landing-view"});
  }
});`

This is still not working with the beta installed but from my understanding it should now? require works as expected.

10

I think filing an issue is best. Keeping track of bugs in a forum thread is a nightmare once many people start posting about different stuff.

11

Yea I know, I just meant that the post kind of makes it sounds like we’re supposed to post in the thread on github which I’m sure is not the intention like you just said.

1 Like
12

Yes, by “application module” I just mean a module that’s part of an app rather than part of a package. In 1.3.3, modules in Meteor packages still use the Babel CommonJS module compiler, just like Meteor 1.3-1.3.2.4, because packages published with Meteor 1.3.3 need to continue working with older versions of Meteor, and the new modules compiler has some runtime dependencies that aren’t in older (pre-1.3.3) versions of the module system. Once most developers are using Meteor 1.3.3 or later, we can consider enabling the new compiler for package modules as well as application modules.

1 Like
13

If that FlowRouter.route code is in an app, then there may be a bug. If it’s in a package, then import statements are still restricted to the top level, and you’ll have to use require there.

14

It’s in an app. I’ll file an issue over the weekend.

2 Likes
15

We’re not able to use other Babel plugins in Meteor packages? That’s a SERIOUS problem and oversight IMO.

I have 150+ packages in my app and I’m using extra Babel transforms (namely transform-class-properties) in all of them. If I’m not able to use my Babel transforms in packages it’s going to be a BIG problem for me and essentially makes 1.3.3 unusable for me which also means 1.4 is going to be unusable and that’s a big problem.

Can it not be optionally enabled in packages? I don’t publish any of my packages, they are used internally since I set them up when they were the only way to manage load order.

It would cost me a couple weeks of time to migrate everything over to be an application and I do not have time for that.

16

If you’re already achieving this somehow, can’t you just keep doing what you were doing? I don’t think we’re talking about any breaking changes here.

17

How do I then update to Meteor 1.4 and continue to take advantage of the continued updates and improvements in the Meteor ecosystem?

I’m using gadicc:ecmascript-hot right now but when the next release comes out it will no longer support .babelrc because that is supposed to be supported in core as of 1.3.3. If you’re leaving out Meteor packages it really isn’t fully supported at all.

18

You can just keep using the same version of ecmascript-hot you were using before, and upgrade to Meteor 1.4, no?

19

It’s going to continue to be improved along with the rest of the ecosystem. It isn’t eminently stable right now as is going to be updated alongside Meteor 1.3.3 because it was expected to have full babelrc support.

It’s also currently tied to a specific version of Meteor due to the dependencies on parts of babel-compiler and other build dependencies.

20

I’m having trouble using my .babelrc file at all.

=> Modified -- restarting.
=> Errors prevented startup:

   While processing files with ecmascript (for target web.browser):
   module.js:338:15: Cannot find module 'transform-class-properties'
   at Function.Module._resolveFilename (module.js:338:15)
   at InputFile.resolve (/tools/isobuild/compiler-plugin.js:355:14)
   at InputFile.<anonymous> (/tools/isobuild/compiler-plugin.js:359:25)
   at InputFile.require
   (/Users/clayne/.meteor/packages/meteor-tool/.1.3.3-beta.1.ecodx3++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/isobuild/compiler-plugin.js:364:23)
   at req (packages/babel-compiler/babel-compiler.js:215:1)
   at packages/babel-compiler/babel-compiler.js:232:1
   at Array.forEach (native)
   at infer (packages/babel-compiler/babel-compiler.js:230:1)
   at BabelCompiler.BCp._inferHelper (packages/babel-compiler/babel-compiler.js:251:1)
   at BabelCompiler.BCp._inferFromBabelRc (packages/babel-compiler/babel-compiler.js:163:1)
   at BabelCompiler.BCp.inferExtraBabelOptions (packages/babel-compiler/babel-compiler.js:150:1)
   at packages/babel-compiler/babel-compiler.js:92:1
   at Array.forEach (native)
   at BabelCompiler.BCp.processFilesForTarget (packages/babel-compiler/babel-compiler.js:40:1)

I have transform-class-properties in my devDependencies.