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 
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. 
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
Changes: https://github.com/meteor/meteor/issues/5788#issuecomment-179570595
9 Likes
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):
react
react-dom
react-router
immutable
redux
redux-thunk
react-redux
yup (client/server)
react-formal
react-formal-inputs
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.
9 Likes
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?