Meteor 1.3 early beta now available

kookoskar · January 6, 2016, 9:51pm

Seems like this commit fixes it. Running Meteor from the latest checkout and now files in imports/ are not eagerly loaded

arunoda · January 6, 2016, 10:21pm

yep. there are loading always. May be @benjamn’s meaning of lazy evaluation is something else.

Anyway, they are modules so I don’t care whether they load or not. So, I simply ignore using imports and use regular files as usually and import as needed.

sashko · January 6, 2016, 10:39pm

No, this was a bug, but will be fixed in the next beta.

kookoskar · January 8, 2016, 9:53am

So, I’ve probably missed a lot of discussion on 1.3.

What’s the plan with Atmosphere/Meteor packages?

Here’s my situation:

Can’t use just NPM modules since most Meteor-centric things are in Meteor packages.
Don’t want to use just Meteor packages since NPM modules are more up-to-date.
Sharing code between your apps is harder, since for that you still need Meteor packages (can’t claim dependencies in modules and sharing the same packages file between all the apps would not be a good solution).

Essentially, packaging in Meteor is not simple anymore. You have to mix and match things. I don’t find that very good. Is MDG planning on doing something about this?

jononomo · January 8, 2016, 2:42pm

I feel like Meteor has been almost unusable as a development environment for me ever since the 1.2 release. I kept hoping 1.3 was just around the corner yet it never seems to arrive. So… has anyone got a time estimate on when this release will finally drop?

casperandersen · January 8, 2016, 4:56pm

maybe this can give you a sense of the direction it is going

github.com/meteor/meteor

Install Meteor packages into virtual node_modules/meteor/ directory.

Previously Meteor packages were installed at /node_modules/<package-name>.
This commit wraps them in an additional directory called "meteor", which
prevents their names from colliding with other installed npm package
names, and also means Meteor package identifiers must now include the
"meteor/" prefix:

  import Blaze from "meteor/blaze"

This change will eventually enable Meteor packages to import npm packages
installed in top-level node_modules directories of apps. That won't work
just yet, though, because the app bundler doesn't yet know anything about
external dependencies imported by packages.

by benjamn on 01:22AM - 19 Dec 15

changed 2 files with 7 additions and 9 deletions.

casperandersen · January 8, 2016, 5:01pm

are you using either:

meteor create/update --release 1.3-modules-beta.*
git clone/checkout/pull meteor from git branch release-1.3

if you want to advance, that’s the way to go. (and you can track the commits and issues step by step)
works for me.

https://github.com/meteor/meteor/commits/release-1.3

benjamn · January 9, 2016, 1:35am

New release!

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

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

Changes: https://github.com/meteor/meteor/issues/5788#issuecomment-170176449

The biggest change is that module identifiers for Meteor packages must now have a meteor/... prefix. So, if you were previously doing import {Accounts} from "accounts-base", you now need to do import {Accounts} from "meteor/accounts-base".

sergiotapia · January 9, 2016, 1:37am

Hi @benjamn - what’s the ETA on Meteor 1.3 final release?

I’m working on a new project early stage, and just want to know if when to brace myself for the migration. Will there be a clear migration path to upgrade Meteor versions? I’m using FlowRouter and React for the view.

etmarch · January 9, 2016, 2:16am

@benjamn Great work! Updated my app from beta version 2 and everything just works

One question - is there any reason in particular why I don’t have to import {Accounts} from "accounts-base" and I just automatically get access to the Accounts global?

benjamn · January 9, 2016, 2:32am

Oh, yeah, Accounts is still auto-imported if you’re did meteor add accounts-base, so you don’t have to import it explicitly unless you want to be absolutely sure you know where it’s coming from. For those (rare?) cases when you want to import things explicitly from packages, the syntax of the module identifiers is now slightly different. That’s all.

sashko · January 9, 2016, 2:33am

Personally I’m doing it to better use ESLint - I need comments like /* global Accounts */ anyway, so I may as well make them into imports, which helps track unused imports, etc.

arunoda · January 9, 2016, 11:28am

This is great. Hope that, NPM module overriding issue is fixed with this.

jamiter · January 9, 2016, 1:58pm

Great to see this release! The “normal” npm support is one of the best things coming to Meteor so far. This really helps to get tons of awesome packages available in Meteor (server AND client) without any special (wrapper) workarounds. Love it!

clayne · January 9, 2016, 4:58pm

Proper imports instead of globals is going to save me SO much time tracking down “system exited with error 1” when I’m trying to reference a global that doesn’t exist. I should get a real compiler error when I miss an import which is worlds better.

goatic · January 9, 2016, 6:35pm

I hope to see globals gone as soon as possible. Thank you for taking the logical first step towards that

reel · January 10, 2016, 9:52pm

Anyone using Flow Router SSR & React? I am having tons of errors… had to revert back. Also, was having ‘unable to import’ from braintree npm modules.

jamiter · January 10, 2016, 10:06pm

Have no fear, Ben is here!

Known issue, hopefully a fix soon!

benjamn · January 10, 2016, 10:15pm

New release!

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

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

Bugs fixed in this release:

jamiter · January 10, 2016, 10:20pm

That was quick! Awesome job!

Meteor 1.3 *early beta* now available

New release!

New release!

Meteor 1.3 early beta now available