Meteor 0.6.5: namespacing, modularity, new build system, source maps!

August 14, 2013 By Geoff Schmidt
Vote on Hacker News

Onward and upward! We're pleased to announce an enormous Meteor release today, Meteor 0.6.5. Meteor 0.6.5 includes a new namespacing system that makes it easier to write large, complex client-side applications in JavaScript; a fully rewritten build system with end-to-end source map support; support for using Meteor to build more than just web apps (you can customize your Meteor stack, for example removing the webapp package if you don't want a web server); an Assets facility for static server-side assets such as data files; and much more.

The theme of this release is making Meteor a flexible platform for building any kind of complex, distributed JavaScript application, whether or not it uses all (or any) of the classic Meteor core packages. The classic Meteor stack remains the default, of course, for the database-backed web apps that remain Meteor's bread and butter. But for those of you using Meteor to manage processes in your datacenter, or using Meteor in industrial controls applications like 3Scan's 3D tissue-scanning microscope, we think you'll agree that these powerful new tools help take JavaScript to the next level.

To update an existing Meteor application to 0.6.5, run meteor update inside the application's directory. If you're new to Meteor, get started on OS X or Linux by running

$ curl https://install.meteor.com | /bin/sh

in your terminal window.

There's too much in this release to go into great detail here but here are the highlights. Full release notes are available in GitHub.

Namespacing and Modules

If you've ever written a large browser-side application in JavaScript, you know that modularity becomes a huge hassle. When "programming in the large" you must avoid global variables, and JavaScript doesn't make that easy. Systems like AMD, CommonJS, or ECMAScript Harmony modules can help, but require app developers to explicitly manage the imports for each individual file in their app. That adds up to a lot of cut-and-paste boilerplate and a lot of repeating yourself when writing a complex client-side app.

Meteor's solution is simple. Each app or package gets its own namespace. Use global variables as much as you want: Meteor generates a wrapper around your code so that they are "global" only to the app or package that defined them. File-scope variables are supported too (just declare them with the 'var' keyword.) And when you use a package, you can see its public exports (and only its public exports) in all of the files in your app. In other words, just use 'meteor add' to add packages and everything just works how you'd expect.

Best of all, it all works identically in the browser and on the server, right out of the box. Meteor is a single JavaScript environment that works the same everywhere.

Package authors, we think you'll find this a breath of fresh air. App authors, you don't need to do anything! We're preserved the zero-friction 'meteor add' workflow that you love, while keeping clutter out of your namespace.

standard-app-packages

Meteor Core has always been made of independent, modular packages, that can be used separately or together — livedata, a client and server for the DDP data sync protocol; deps, an ultra-lightweight reactivity system; spark, a library for updating DOM nodes in realtime as data changes. But up until now, the core Meteor stack was automatically included in every Meteor app.

That changes today. After updating your app to Meteor 0.6.5, you'll see a new package in your project — standard-app-packages. This pulls in the standard packages that used to be included in every app by default. Now, if you want to pick and choose which parts of Meteor Core you'd like to include, you can remove standard-app-packages and add back in whichever parts you want for a fully modular Meteor experience.

Since Meteor is just a collection of packages, you can even take out the HTTP server by removing the webapp package. That lets you write command-line tools, DDP clients, and server daemons that don't include a web server at all.

Limitations: Build system support is still a little rough for command-line apps, but we are already using it extensively inside MDG and it will improve over the coming releases. And some of the core packages have more interdependencies than they should, so not every possible combination may work yet, but this too will continue to improve.

To celebrate this transition we've also begun the process of renaming APIs out of the Meteornamespace. For example, Meteor.http.get is now HTTP.get and Meteor.connect is nowDDP.connect. See History.md for the full details. The old names are supported for backwards compatibliity.

Source maps

Meteor's build system now has first-class, end-to-end support for source maps. A source map is tracked for each file as it works its way through each stage of the build pipeline. Source maps are used to decode server-side exceptions and (in development mode only) source maps are served to browser-side debuggers that support them.

That means that if you like CoffeeScript, just add the coffeescript package, drop a .coffeefile into your application, enable source maps in your browser's debugger, and enjoy source-level CoffeeScript debugging on the client and CoffeeScript stack traces on the server.

It all just works! And not just for CoffeeScript, but for any build plugin that you add to your Meteor project.

As you can see, we're doing a ton of hard work to make the Meteor build tool the best way to build any complex JavaScript application — no matter what language it's written in.

Assets

The new build system also includes a long-overdue omission: server-side data files. Just put any extra data files used by your server in a private directory at the top of your app, and the build system will bundle them up along with your code and make them available through the AssetsAPI. We'd like to eventually support this API in the browser as well. Let us know if that's a priority for you.

And more

A lot has landed in 0.6.5. See the full change log athttps://github.com/meteor/meteor/blob/devel/History.md.

Package authors will want to check out the new Writing Packages section of the docs for information about exporting symbols, creating build plugins, and new package system features such as weak and implied package dependencies.

Thanks to GitHub users btipling, mizzao, timhaines and zol for their patches.