Meteor 1.3 *early beta* now available

I updated to 1.3 and things aren’t working so I want to roll back to 1.2. How can I do this? Thanks.

meteor update --release 1.2.1 seems to work.

Yeah I tried too and it seemed to break a bunch of my globals, like collection definitions and routes.

I’m sure the modules team would appreciate some info/reproductions! We hope that anyone will be able to upgrade without any issues for the final release.

1 Like

Version control, version control, version control :wink: Git is a magical world og wonder!

With 1.3 globals aren’t just global anymore. You have to export them to global using global.thing = thing. So thats not backwards compatible and will break 95% of peoples apps right now. Or am I missing something?

Not being backwards compatible means unhappy people and not keeping the 1.0 promise, so I’m curious what you guys come up with. Personally I like the fact that things are no longer global by default, but we’ll have a lot of “who moved my cheese” discussions ;).

@sashko, I don’t think you need a reproduction for this, right?

You could, but you won’t have the ability to import modules by name; you will be limited to importing by path.

Hum, the Date object need also to be prefixed with global… that’s a bit too much, don’t you think so ?
However i guess this is more a bug linked to the Babel upgrade than an intended feature.

1 Like

This worked perfectly to downgrade back, however I am now unable to publish to galaxy.
It simply comes up with this in my console:

Error deploying application: Internal error

However nothing in the Galaxy logs at all.

The application runs fine on my dev machine - even when I force it into --production mode.

Sure!! So after upgrading to 1.3 I couldn’t run the app anymore, I kept seeing this error for each of my collections. I have the collections defined in a collections.js in lib folder.

W20160131-22:56:04.287(11)? (STDERR) 						throw(ex);
W20160131-22:56:04.287(11)? (STDERR) 						      ^
W20160131-22:56:04.287(11)? (STDERR) ReferenceError: NewsFeed is not defined
W20160131-22:56:04.287(11)? (STDERR)     at meteorInstall.lib.collections.js (lib/collections.js:19:1)
W20160131-22:56:04.287(11)? (STDERR)     at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:183:1)

Then when I tried to define them as globals I started seeing other errors which look to come from packages, like this one:

I20160131-22:57:40.462(11)? Exception from sub id undefined ReferenceError: NewsFeed is not defined
I20160131-22:57:40.463(11)?     at Subscription.<anonymous> (server/publish.js:5:11)
I20160131-22:57:40.463(11)?     at packages/matb33_collection-hooks/collection-hooks.js:275:1
I20160131-22:57:40.463(11)?     at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
I20160131-22:57:40.463(11)?     at Subscription._handler (packages/matb33_collection-hooks/collection-hooks.js:274:1)

Even then, none of my FlowRouter routes were working. I was seeing errors in my browser console saying that I had no routes setup. :frowning:

Then as per my last comment, downgrading has worked fine for development.
Galaxy deployment isn’t working though. I am pretty sure it’s related to the upgrade and downgrade. However the error is so vague its difficult to tell/debug.

Let me know if this is helpful or not, happy to send more information but it seems like this is a pretty common issue judging by some other comments.

Ok. Thank you. So basically, everything should go into imports directory, so the build process does not brake?

1 Like

Sorry for being unclear about this. I didn’t mean the default globals in JS. Just the ones you define yourself by omitting var in JS or by adding it to the outer scope in CoffeeScript (@thing = thing). These break in 1.3 at the moment.

You should probably just check out your commit with Meteor 1.2.1 from source control. Upgrading / downgrading sounds like an unnecessary headache.

1 Like

New release!

To update to the latest beta release, run the following command in your meteor project:

meteor update --release 1.3-modules-beta.6



I don’t know why but when I do this in “beta.6”

import { obj1, obj2 } from 'this-file';

// this-file.js
export default {
  obj1: 'value1',
  obj2: 'value2'

It returns null for both obj1 and obj2

Because that’s correct. You can get values like this from an import. You need to do this in the file to do that:

export const obj1 = 'value1';
export const obj2 = 'value2';

You can import all exports like this:

import * as allExports from './this-file'

That means you are exporting (as default) an object, and inside that object you’ve got properties, so, alternatively to what @arunoda said, you can import it like this:

import foo from 'this-file'
console.log(foo.obj1, foo.obj2)

where foo is a name arbitrarily chosen by you.

import whatever from 'this-file'
console.log(whatever.obj1, whatever.obj2)

Meteor 1.3 beta 6 is looking great.

I was able to literally make ALL my third-party dependencies come from NPM instead of Atmosphere. All of these just worked out of the box when imported on the client (and server):

yup (client/server)
mysql (server)

Unfortunately, there are some packages like Joi that I couldn’t get working because it had an obscure dependency issue (but that’s okay I found Yup, which is a much lighter version, is still decent, and has a “nicer” maintainer than Joi’s (lol)).

I think that at this point, if there were faster build/reload/(hot load?) times, like Webpack-type speeds, and had reactive GraphQL, Meteor would just explode with so much more awesomeness.


huh…i’ve updated from 1.3beta2 to 1.3beta6 and got an error of Cannot find module 'meteor'. In 1.3beta2 I did something like import {Meteor} from 'meteor' Any idea?

@seanh import {Meteor} from 'meteor/meteor' should work, try that?

1 Like