Installing & Configuring Babel

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kent C. Dodds: We're going to install two things, which again, you already have these things installed so I'm just gonna add it to our dev dependencies here, babel-cli, and the version that we have, I believe, is still the latest version, 6.11.4 and we're also going to install the babel preset, preset-es2015.

[00:00:29]
So we get all the plugins that we need and 6.9.0 is the latest version. And then to configure it, it's actually kind of small, so you can configure Babel a couple of different ways. You can configure it right in your package.json, or you can add a Babel RC file in your root directory.

[00:00:54]
Because what we have is pretty small, we're just gonna stick it right in our package.json, and it goes right on the root of your package.json object. We'll create an object called babel with a presets array with es2015 that references the babel preset es2015.
>> Kent C. Dodds: And this is where you would put other presets.

[00:01:19]
If you wanted to add plugins, you're gonna add plugins here. And you'd install some plugins like module alias, one of my favorites for one of my projects or another preset is react. That one's awesome cuz it enables me to use the awesome JSX. So, ES2015 is the only preset we really care about here, and then we'll add a script to build our not to build our Babel stuff.

[00:01:53]
So it's a build script right here up at the top and we'll use the vowel CLI will start out with just babble. With specifying that out to directory as dist, that's the like its anything arbitrary you can call it build or you can call it out or you can call whatever you want.

[00:02:13]
I like to call it dist its short for distribution cuz this is what we're gonna distribute on the npm registry. And than our input will be src, so the source directory so we want to transpile the stuff that's in the source directory to the dist directory. You should be able to run your build script now and it'll create a dist directory for you.

[00:02:44]
>> Kent C. Dodds: Pop that open and take a look at the transpiled code. You'll notice that it doesn't actually look transpiled at all, it looks exactly like the code that you wrote. And that's because what we wrote was ES5, so it doesn't need to do anything. But if you start making changes, like for example, let's just take off a couple semicolons.

[00:03:04]
Hooray, we'll run the build again. Then we'll look in here and those semicolons have been added so you don't have to write your code in with semicolons anymore. Babel will add them for you. And ESLint will warn you when there's a problem that no semicolons would cause so that's why I don't write with semicolons anymore.

[00:03:24]
But yeah, so you can start using all kinds of ES6 features. We could say, swap these out with import from and we could change this to a const. We're gonna need to update our ESLint config here in a little bit, but we'll just save that for, well, I'll just show it to you.

[00:03:46]
You don't need to do that, but yeah, ESLint needs to make some changes. But see now we can use imports, and it'll transpile those down to require statements. That's the default, is it transpiles imports to a CommonJS. And then also we hhave this use strict here. ES6 comes with implied strict mode.

[00:04:08]
So when you use ES6 features then it says you're in ES6, I'm gonna assume you're in strict mode, which is cool. So if we then remove the use strict, then Babel will add it back for us, which is awesome. So yeah, you can use ES6. There are a couple of other things we need to do but I'm going to stop for questions.

[00:04:38]
>> Kent C. Dodds: Okay so Tim is asking, if using Babel RC, would you just remove from the package JSON, any other changes needed? No, if you're using Babel RC or sorry you are correct, there are no other changes needed. Yeah, if you're using Babel RC then you don't need to have anything in your package JSON.

[00:04:55]
I'm not sure which would win in a conflict. I've never tried it. You could try and see. Good question, any other questions? Okey doke. Sweet. So has anybody noticed any potential issues here or things that we might not want to have happen? So if we think about this as we're going to be distributing the dist folder, that's what we want to put on the npm registry.

[00:05:28]
We might not care to send our test to the npm registry. It doesn't really provide any value to anybody. We're transpiling this test file when we don't really need to so it's wasted resources so we're going to exclude that. If we want to author our tests using ES6, which we do and that's what we'll set up next, we're going to do it a little bit differently.

[00:05:55]
But yeah, we don't want to transpile that, we don't want to ship that to people using the npm registry. So we're going to fix that here in a second. Federico is asking since you used fixed dependency versions what mechanism or workflow to use to update your dependencies at any given time?

[00:06:11]
Great question. So there are a couple solutions to this one. One that's really popular for open source projects and closed projects alike is greenkeeper.io. I was gonna mention this later, but why not mention it now? This is actually a really cool service. You just plug it into your GitHub repo and anytime there's, it will find all of your packaged .json dependencies.

[00:06:40]
Any time one of those receives an update, you'll get a pull request with that dependency updated and if you have Travis CI set up then it will run the CI and you'll see, my tests still passed with this version updated. You just merge the pull request and you're done.

[00:06:54]
It's really really cool. I actually don't use this workflow. Maybe I should, but I can show you an example of what it looks like on the project that I contribute to, which incidently is Ghooks. So if we go to the pull requests here, you'll see a whole bunch of these that haven't actually been merged because some of them are updating things that we can't actually merge yet.

[00:07:22]
But this is what it looks like. So the file's changed. It's just bumping up there to commit us into the latest version and because we have this, whoa, something weird just happened. Because we have Travis set up on this, then it's gonna run continuous integration. It looks like it fails for some reason.

[00:07:41]
And I'm pretty sure that the reason is that commitizen dropped support for older versions of node and we still run our Travis stuff on older versions of node so, that's why we haven't merged this one yet. But also if you have CodeCov integration setup then you'll also get CodeCov report in here.

[00:08:00]
So you'll see if potentially dependency would mess up your coverage stats which I'll be really surprised if it did, maybe an update to nyc could or something. But, yeah, that's generally the way that I manage it is I use a package called David and David will, it provides a COI where you can say, david update.

[00:08:24]
And it will go through, look at all of your outdated packages, update them for you automatically and then I just run the validate script. So I kinda like to have control over when things are updated but honestly, if you want to use something like Greenkeeper.io, I think that's fantastic, and maybe I should probably do that too.

[00:08:43]
Good question, Federico. So a question from Mike, transpiling into a dist folder seems to be the standard for all the webs I've seen. If you have an ExpressJS server with ES6, do you transpile that too? Yeah, so if you need to run, you need to transpile anything that won't run natively in the environment that you're delivering to.

[00:09:06]
So for our library, we want people using old versions of node to use our library, and so we're transpiling it. And we also want to author in ES6. If your Express server is running on node 6 and you don't mind not using ES6 modules, then node 6 supports pretty much every other node or ES6 feature and so you don't have to transpile that if you don't want to.

[00:09:34]
However, there will always be cool new features that are not yet implemented in the environments that you're delivering to like Async Await or this is kind of petty, but I really like dangling commas and function calls in our primer list. That's like where you can do well, just say function foo and you have bar baz and boo and having a dangling comma right there.

[00:10:06]
And even when I when I call it, I say like 1, 2, 3, having a dangling comma there. It's really nice for version control, so I can get, we'll show that in a much nicer way. So, anyway, that's a feature that is coming that I really like using, and so I like having Babel to fix that for me.

[00:10:29]
So, yeah, as far as for an application where you build, what directory you have it transpiled down to. Yeah, I still call it dist. I just like using distribution. It makes sense to me. Other questions?
>> Speaker 2: So you may have covered this. So forgive me if I'm asking something you already covered but, the case where you want to build a distribution for many different versions, so you might wanna have one that's ES6.

[00:11:04]
You might wanna have one that's ES5 and down, can you do that?
>> Kent C. Dodds: Yeah, so you could totally do that. It would be a little bit more complex, but-
>> Speaker 2: Would you want to do that? I mean, is there a reason?
>> Kent C. Dodds: Yeah, you could potentially want to do that.

[00:11:18]
There could be some performance things, like if it's a really, really heavy performance thing. For our library we don't care. It can take a couple of nanoseconds, or a couple more nanoseconds. I don't know how fast it is, but it's probably pretty fast. But if it's heavy performance, it's possible that you'll get better performance out of native features, so you don't wanna transpile everything.

[00:11:41]
So you could have multiple dist folders or something for each one. One really solid use case that I can think of for having an ES6 distribution of your module though is for tree shaking. So I'm not gonna go too deep into the concept of tree shaking but it basically allows people to pick and choose the pieces of your library that they use.

[00:12:06]
And so if you distribute a version of your library that uses ES6 modules, and then people consume that with something like Webpack, or Rollup, or Browserify, then they can just pick and choose the pieces of that library that they're actually using, which can significantly reduce file size. So this is really important for browsers, mostly.

[00:12:31]
So yeah, there is a use case for doing different distributions, for sure, but most of the time, you don't wanna do that until the benefit outweighs the cost of the complexity. Sweet and again, I should say that the benefit of adding Babel to this teeny tiny project definitely doesn't outweigh the complexity of adding Babel.

[00:12:54]
But it's kinda fun and in future libraries, hopefully this will be instructive to you.