This will work alright in the case of a package that I write myself, but what about if I want to release a package on Atmosphere?
Will there be a way to tell the compiler that a certain package is required as a top-level NPM package, or to have something like a weak Npm.depends such that if the if the NPM package is included at the top level, it doesn’t get included, otherwise it does?
@clayne I think these questions deserve their own forum thread, if you wouldn’t mind starting a new topic. I have some ideas, and I’m sure you do too, but I don’t want this discussion getting lost in the larger 1.3 announcement thread.
Yes, that would definitely cause problems. How does this package work without a main field or an index.js file?
Hey folks, as of today I’m getting back to work after some holiday downtime, and I’m hoping to spend this week responding to all the feedback and ideas above. Thanks for all the input, and for your patience!
This thread has gotten rather long, so if there’s something I don’t respond to in the next few days, don’t hesitate to resurface it. If it feels like a distinct topic, starting a new thread might be a good idea. Just @mention me and link back to the original post(s).
Yep, that’s the plan for 1.3: you have complete control over the contents of node_modules directories in your app, and Meteor will bundle those modules into your app when you deploy.
Future releases may introduce new features that help with managing npm dependencies, but we believe that can wait until after 1.3.
Created a new thread:
Cool stuff. Two package managers feels so dirty, but hopefully this will work out.
I don’t know what the deal is, but the imports/ directory thing is definitely not working for me. Maybe I’m just stupid. Tried /imports/, /server/imports/, /client/imports/, but files in those folders still get eager-loaded.
But I like this. It’s better than I expected. Well done.
Seems like this commit fixes it. Running Meteor from the latest checkout and now files in imports/ are not eagerly loaded 
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.
No, this was a bug, but will be fixed in the next beta.
So, I’ve probably missed a lot of discussion on 1.3.
What’s the plan with Atmosphere/Meteor packages?
Here’s my situation:
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?
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?
maybe this can give you a sense of the direction it is going
are you using either:
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.
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".
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.
@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?
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.
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.