Any ETA on a release candidate? Sorry, pretty excited about this release 
1 Like
And any upgrade guides available?
In case you missed it, beta 16 is out:
release/METEOR@1.3-beta.16: Bump package versions for 1.3-beta.16 release.
@benjamn benjamn tagged this 2 days ago · 8 commits to devel since this tag
What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
New release!
(thanks @discdiver)
To update to the latest beta release, run the following command in your meteor project:
meteor update --release 1.3-beta.16
If all goes well with this beta, the next release will be the first 1.3 release candidate.
See what changed on GitHub.
9 Likes
Woohoo! Awesome news @benjamn - a big thanks to you and everyone else making 1.3 happen. We’re almost there - very exciting! 
1 Like
@corvid I also started using export default and believe it’s a great way to satisfy the default (common) case while also providing additional functionality that may not always be required.
Propagating process.env.NODE_ENV to the client. Awesome, that’s super useful!
1 Like
I think we’ve had this since beta 12 at least? I use beta 12 and I can access process.env.NODE_ENV in the client.
Right, process.env.NODE_ENV has been available on the client for a while, since many React-related packages rely on it, but only recently (as of beta.16) was it determined by the actual contents of process.env on the server. Now you can do NODE_ENV="testing" meteor run, open your browser console, and process.env.NODE_ENV will actually be "testing" instead of "development".
2 Likes
@benjamn - do you have a link to the file that implements client-side environment variables?
We have the clinical:env package which implements a lot of similar functionality. It would be nice to merge functionality.
1 Like
Is there any way to import from root of the project?
Like:
import 'imports/some-module';
Instead of:
import '../../../some-module';
?
Try a forward /?
import {thing} from "/imports/some-module"
The string literal here is an absolute module identifier. If you’re ever unsure of the absolute path to use, you can find out the absolute module identifier for the current module from module.id.
Oh… so easy. Wonder why I never tried this.
Thank you!
Here’s the logic we use to ensure process.env.NODE_ENV has a value.
Here are the environment variables we whitelist for the client-side process.env.
Here’s where we pass the server-side meteorEnv object to the client.
Here’s where we make sure process.env reflects meteorEnv.
In short, I think this strategy is still perfectly compatible with clinical:env, but please let me know if you have any trouble setting additional environment variables!
1 Like
How do I know though how to import a certain npm package?
For example with react it’s like this:
import React from ‘react’;
So the second react is the npm package name, right? How do I know to import “React” though? This goes for other packages as well of course, such as how do I import cloudinary and cloudinary-core for example? They both seem to be addressed with “cloudinary”, so how do you go about importing these things?
Each package is different: you’ll have to read the documentation for the package(s) you are interested in, because it’s up to the package author to decide (and tell you) what a package exports and how to use that package.
Ask the cloudinary author.
Thank you for the links! This looks like it’s totally compatible. What I’ll probably do is swap out the meteorhacks:inject-initial package for the new meteorEnv object, and simply decorate it with additional variables. Then, if anybody wants to have extended ENV support, they can drop in the package.
Hmmm… with meteorEnv support now in core, maybe I should rename it to clinical:extended-env.
1 Like
rc0 is out! trying it right now 
rlease is geting closer and closer I guess 
2 Likes
rc1 is out as of 3h ago: https://github.com/meteor/meteor/releases
But there’s no point in trying it on Windows if they haven’t fixed this issue from 1.3-beta.16: Can’t find npm module ‘meteor-deque’