Don't ship untranspiled code

transpile-your-things.md

When Babel 6 came out, it was hard for a lot of packages to upgrade because it was essentially an entirely different category of thing than Babel 5. So what happened was that some packages upgraded, and some didn't — at least not straight away.

Some projects took the prima facie enlightened view that packages should expose untranspiled code, so that the consumers of that code could determine for themselves what needed to get transpiled based on the environments they supported.

That was a costly decision. If I was the author of an app that was using Babel 6, I couldn't import a library that was still using Babel 5 and shipping untranspiled code (because the configs were completely incompatible), and vice versa. Frankly, it was a bloody nuisance. We are bad at anticipating these sorts of issues. It will happen again at some point.

Adding a few extra bytes to pkg.main or pkg.module is a small price to pay for things just working. As well as avoiding the aforementioned headaches, it means that your builds are a lot quicker. I don't want to run my node_modules through Babel.

But it might not be a few bytes!

Right. So you're a library author, and you want to use async/await and all that stuff. You have a few options here:

1. Don't. It transpiles badly. Honestly, we managed for long enough without it — it's not that hard.
2. Say that you don't support environments without async/await. That's totally fine. I don't support environments without Array.prototype.filter.
3. Include your src code in the npm package. If someone really wants to use your futuristic code in an environment you don't support, let them. Just make sure you also include pre-transpiled bundles.

The golden rule

A lot of developers believe that the priority is to ship the leanest, most optimised code possible. I disagree. The priority is to ensure that people can consume code with the least amount of faffery. A novice developer should not have to learn about transpilers in order to use your library.

Shipping code that works out of the box is just basic politeness. I've said this in the past, and I stand by it:

It’s the difference between giving someone raw ingredients and a cooked meal — if you went to a restaurant and ordered a burger, you’d be pretty mad if they gave you half a pound of minced beef and a frying pan instead.

Shipping the leanest, most optimised code is something experts care about. Experts have the knowledge and incentives to invest time in the kinds of workflows that involve transpiling other people's code. That should not be the default.

Babel 7's lack of support for targeting specific ES versions forces me to go with option #3 sans pre-transpiled bundles. As a library author, the decision about which browsers to support is not mine to make.