MDN Brings Browser Vendors To One Table

Have you heard the great news about documentation on the web? Mozilla, Google, Microsoft, and Samsung have made a join commitment to directing documentation focus for their browsers’ web standards to the existing Mozilla Developer Network (MDN).

This is a huge step for the web, for a number of reasons.

First, this commitment means that, with these four vendors committing to combining their documentation, differences will be a lot more obvious. I think this is going to create a big incentive to the vendors towards both compliance and matching pace with each other.

Second, just like the great resource of caniuse.com, developers are going to have even more one-stop shopping for sizing up the differences between browsers on a particular feature, determining when new toys are available consistently enough to use on broad-usage projects, or finding the nuances of working around those differences to provide stable experiences to all your users, regardless of their devices and software.

Lastly, and I think most interestingly, this news is amazing for all that it isn’t. It isn’t particularly shocking or surprising. It gives us a new leg up on cross-browser development, but the gaps it closes aren’t actually that large to begin with. Five years ago? This would have much bigger news then. Ten years ago? This would have been essentially unthinkable. We’ve come a long way to get here, but the vendors cooperation has improved so much that this news, while great, honestly feels almost inevitable.

That feeling gives me a lot of hope for the success of this initiative!

Publishing ES6 Modules on NPM

I had an adventure over the last couple days with ES6!

There was a pattern I’d already used in a few of my React projects to make ES6 classes a little nicer. ES6 did a lot to make working with this mechanics nicer, but there was a still a gap that bit me: the sugar provided by ES6 classes don’t extend to keeping method bound to instances of the class.

Maybe you, like me, would expect this to work:

But, like non-class methods on any regular Javascript object, onClick will loose its binding to the Counter instance. There are a few existing solutions to this, but I wanted one that didn’t change the syntax of defining a method on these classes.

Enter AutoBind, via my new NPM module es6-class-auto-bind:

You can read all about the AutoBind class [at its NPM readme](https://www.npmjs.com/package/es6-class-auto-bind) and you can read on to learn about what I learned to publish this ES6 module on NPM, consumable by other ES6 (and even ES5) code.

The Problems of ES6 on NPM

For the moment, NPM is a tool for distributing and installing ES5 modules. While you can point it at any types of files you want (some people have even used NPM to distribute C libraries!) the mechanisms that install and then import those modules in NodeJS (or Browserify) are expecting ES5 modules, so they won’t do your users any good.

There are two problems we’ll face shipping ES6 code directly.

First, most of the ES6 code we might ship would be completely useful for consumption by ES5 code. My choice of ES6 shouldn’t prohibit anyone from consuming my libraries. We want to publish something that both new ES6 and legacy ES5 code can make use of without caring much about what’s inside. And, we want to do so without carrying build constraints on our users, like requiring they integrate BabelJS into their pipeline when they haven’t done so already.

Second, for those consumers of our module who already are using BabelJS or another transpiler to ship their ES6 to ES5 runtimes, importing ES6 code installed by NPM is probably not going to work out of the box! Browserify here is a big culprit, refusing to apply configured transform plugins to packages installed from node_modules/, only to those from your own local project.

Now, I understand Webpack may be better about enabling this usecase, but I don’t want to impose that move to people still on Browserify (and I still want to support ES5 users), so I wanted a solution that works for everyone.

How To Combine Packaging and Transformation

The solution is to tranform our ES6 module to ES5 before publication, and idealy to automate this. We want to transform it into an ES5 version of itself and tell NPM to publish that version of our module, instead of the original ES6 version. Here’s how we do it.

We’ll put our two versions into a src/index.js and build/index.js. Transforming the first to the second is straightforward with BabelJS, which we’ll install first:

Now we have both versions, and we only need to tell NPM what we actually want a consumer to get when they require()or import it.

Great! But we still need to make this happen automatically any time we issue an npm publish, never allowing us to publish a version that isn’t compiled from the most recent version of the ES6 source.

We’ve defined two npm run scripts now: compile and prepublish. We can run npm run compile to test our preparation any time, and NPM itself will invoke prepublish before any new version you attempt to upload via npm publish. We’ve now configured our module to transform from ES6 to ES5 before publication to NPM, where it is consumable by any other project that needs it!

We’re almost done at this point. There is a last step we can take to make the whole process more consistent between ES5 and ES6 norms. The ES6 module syntax’s export statement is largely comparable to exports.member = somethingstatements in NodeJS’ ES5 modules, and BabelJS will transform them appropriately. But export has a special form for exporting one member as a default, to be handed to an importing module when it only asks for a single thing from the module.

The problem is BabelJS transforms this by exporting these defaults with the obvious name “default”, and accesses the .default member of a module when performing a default import. But, this means ES5 code would need to access the .default member explicitly, with the unfortunate requires() invoking as require(“es6-class-auto-bind”).default. We’d like to get rid of that ugly .default at the end, obviously.

It turns out this is a behavior BabelJS did have but changed. It is also a behavior we can restore through a plugin that re-implementes the deprecated behavior. I think allowing it to be optional like this is just fine. We just need to install the plugin

And change our compile script to enable the plugin

And, that’s it. Everything works great now. This is how I was able to ship my ES6 AutoBind class via NPM and install into other ES6 classes, seamlessly building my ES6 code across packages. Very exciting!

Here’s the whole portion of the package.json necessary to make this work.

Stay subscribed for follow up posts on the subject, as I dig into how to expand this to:

  • Ship a copy of the ES6 code in parallel and pull that into the project’s own transform options
  • Understand how to expand this approach to packages with more than one module