Creating an Open Source JavaScript Library on Github

Babel Register & Istanbul

Kent C. Dodds

Kent C. Dodds

Professional Trainer
Creating an Open Source JavaScript Library on Github

Check out a free preview of the full Creating an Open Source JavaScript Library on Github course

The "Babel Register & Istanbul" Lesson is part of the full, Creating an Open Source JavaScript Library on Github course featured in this preview video. Here's what you'd learn in this lesson:

Now that the library is using ES6 syntax and transpiling with Babel, the test scripts will not run. Kent explains why this is happening and introduces the Babel Register plugin which will help alleviate the problem. He also talks about why the Babel plugin, Istanbul will now be used for code coverage.


Transcript from the "Babel Register & Istanbul" Lesson

>> [MUSIC]

>> Speaker 1: There are a couple of things that I wanted to talk about before we start covering, during test coverage or transpiling our tests. One thing is, just as kind of a pro tip, as you're working through these solutions, if things aren't quite working for you and you're not sure why, then this is something fancy you can do with git to figure out what's wrong.

So I'm still on the previous branch, and I've done a little bit of work, but it's not working for me, and I'm not sure why. So I'm gonna say git diff, and I'm gonna provide the name of the next branch, 7.0-transpile-source, so this is the one that actually has the solution, and that will show me what's different between what I have right now and the next branch.

And so I see that I haven't set up my ESLint stuff yet, that's not really important to what I'm doing right now. There's something in the git-ignore I need to do. And then there's something in the package.json that's different, it looks like I have a typo here. And so I actually use a really cool thing called diff-so-fancy that does this cool highlighting thing for me.

You should look that up, it's awesome. But yeah, you'll at least be able to see that there's a difference between these two lines and figure out what that is. And then I haven't done any ES6 in that index file. So it's git diff and then the name of the next branch will give you the difference between what work you've done and what work you have yet to do, and potentially the difference between actually having the right solution or not.

So let's all check out force 07.0-transpile-source. Yeah, and sorry, one other thing before we get to transpiling the source, or transpiling the test. So this dist directory has been added to the gitignore, so I'm not going to talk too much about this, but I do want to reference you to a blog post.

Let's see, generated. So at, if somebody could put that in the chat, that would be awesome. But this explains why it's a really bad idea to commit generated files to your repository, [COUGH] at least in open source projects. There are use cases for doing this, but in open source projects, it's a bad idea, so don't do it, that's why we have that git ignore, so check that out.

Yeah, great and maybe we'll have a little bit of time at the end I can talk about a couple of these things that I'm kind of breezing over. Great, so now if we run our tests, we're going to see an error here. It looks like nyc has no idea what's going on with life right now and, yeah, this area is not at all helpful.

You go up to the very top and then you get Unexpected token import. So our tests don't know what import is, node doesn't have any idea what import is yet. Soon, hopefully, but for now we're gonna have to do something with our tests. And, like what was suggested earlier, we could run our tests on the transpiled code, but there are a couple of drawbacks to that.

One is, well, probably the biggest one for me is the code coverage report. So If we look at our dist, we have some code in here that's generated by Webpack, or sorry, I'm still in yesterday. It's generated by Babel. And we would have to do some fancy things to make sure that we have coverage on these lines of code.

And honestly, I don't really care about getting coverage on these lines of code because Babel has done that already. You don't test the dependencies of your library or the tools that you're using, you test just the stuff that you have. And so that's part of the reason why we're just gonna test our source code.

And so we need to be able to transpile our test code and our source code, and we're gonna do that on the fly using something called Babel Register. How many people have heard of Babel Register before? Any from online coming in in a little bit? [COUGH] I imagine some people have heard of Babel Register.

Basically what Babel Register is is like, you can do some pretty fancy things with the require statement in node. You can hijack it. And so, anytime somebody calls require through, yeah, see there's Mathew, he's heard of Babel Register before. So, when somebody says, okay, require this file, then you can say, not so fast.

Let me do something first and then I'll give you back the module that you're requiring. So the cool thing about that is with Babel Register, it hijacks the require function and before it gives you the module back it will transpile it. So it does it on the fly.

This is not all performant. You'd never wanna do this in production, unless it's a teeny tiny app for your spouse or something, that would probably be fine. But, yeah, it's great for tests because it's not so terribly bad with performance that it's something you can really notice. Now [COUGH] there are a couple of ways for us to do this, but Mocha has kind of a built in way for us to transpile our stuff on the fly using Babel Register.

And so that's, actually sorry, no we're not going to use Mocha's built in way, we're gonna use something from nyc. Sorry, I got confused with the way that things used to be. Things change fast with JavaScript. So Babel Register is one thing that we're going to use, [COUGH] and that's so that we can transpile our source code.

But we're also concerned about doing code coverage, and because nyc can't cover our source code, yeah, can't cover our source code because it's in ES6, we're gonna use a Babel plugin to instrument our code for code coverage, so we're going to install Babel plugin. And we'll get to that point, and then we'll deal with some of the problems once we get there.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now