@benjamn, as indicated in the release notes, Meteor 1.3 will introduce Ecmascript async and await keywords. Since Meteor used fibers to runs asynchronous code in a synchronous style until now, I wonder if these two strategies will co-exist for some time, and if the new keywords will be recommended over usage of fibers (I‘m also not quite sure of the consequences of this series of commits but I guess that’s related). Concretely will we have to insert a await keyword in these kind of statements:
How do we find which commit on GitHub 1.3-modules-beta.1 is made from? EDIT: After cloning, I see the tag release/METEOR@1.3-modules-beta.1, but the strange thing is I don’t actually see this tag while in GitHub’s UI, which is where I was originally looking.
Now that users populate node_modules themselves, are there any implications of using NPM v2 vs v3?
I currently use a package.json with some devDependencies (for some linting tools) and I noted in the current 1.2 docs that:
For compatibility with node.js tools used alongside Meteor, any directory named node_modules is not loaded anywhere. node.js packages installed into node_modules directories will not be available to your Meteor code.
So this will be different in 1.3. If I move all my meteorhacks:npm packages into package.json and run an npm install then Meteor will now be reading everything in node_modules. I guess that as my current modules are devDependencies that this actually is okay.
@timfletcher That statement is essentially still valid with a new exception: files from node_modules won’t be loaded automatically, just as before, unless you explicitly load them with an import or require statement somewhere in your code. If you never import anything from node_modules, then those files will never load. However, if you have files outside of node_modules that you aren’t importing anywhere, then those files will be loaded automatically by Meteor unless they are inside any folder named imports.