Creating an Open Source JavaScript Library on Github

Ignoring and Copying Files

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 "Ignoring and Copying Files" 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:

Kent continues to configure Babel and demonstrates a few additional features. He ignores any test scripts so they are not included in the distribution directory. He also uses the --copy-files flag to copy any non-JavaScript files like the JSON data file into the distribution directory. Finally, he adds the rimraf Node module to remove the “dist” folder each time the build script is run to ensure it’s clean and up-to-date. The code for this example is on the FEM/07.0-transpile-source branch.


Transcript from the "Ignoring and Copying Files" Lesson

>> [MUSIC]

>> Kent C Dodds: Like I said, you probably don't wanna distribute your test files. And you don't need to transpile those either. So, we're going to add, right here, --ignore *.test.js. I should make a pull request to have that be automatic, that would be cool. So now you see in the output that it is only transpiling source index .js not the test, but the dist directory still has my test file in there.

That's not a big deal because I could just delete it right, and it won't show up again. As I'm adding files and removing files, like that's not cool. So what's better is to clean everything up so that it's in a solid state, and then run the build. And so with npm scripts, I can have something happen before any, like a particular script.

And that's done by creating a script with the term pre, and then you can say prebuild, for example. So before you run the build script, I want you to run this script. And the script that I want to run is some command that will delete this. So if I'm on a Mac, I'm going to say rm -rf dist, and I guess if I'm on a Windows, it was rm dir I think.

But I want to have a script that works across platforms because we are gonna use this in our validate script and I'm gonna have contributors from both Windows and Mac. So I'm going to use a package called Rimraf to do that, rimraf, you normally just install this, so I think the latest version is 2.5.4 which you have installed already.

And you'll just use that binary, rimraf dist. So then if you run your build again, you'll see that at first run pre built script and than it runs the built script and your dist directory should be clean, just have what you need in them.
>> Student: And that's just by convention anything having pre in it will run, if it's the same name as another build?

>> Kent C Dodds: Yep and then incidentally, we could also run the prebuild script by itself. I haven't tried this before but if I did, preprebuild: "echo hi". Nope, looks like it doesn't. I'm not sure how it's implemented, but I guess it's not implemented in a way that will work. That's kind of funny.

>> Student: So just a question then on the same scripts and naming, you named that watchTests, does that any type of convention or did you just do that?
>> Kent C Dodds: It's fairly conventional, like for example, npm-run-all has a handy thing that I think actually, yeah, we're gonna use it later for our build when we actually are gonna make multiple distributions like we were talking about.

One for browser, one for CommonJS. And so, yeah, npm-run-all utilizes this convention to allow you to do a couple of fancy things that we'll look into later. So the convention of that colon right there. As far as the actual name of this script, maybe that's a little conventional.

I don't know, I've seen it in some places. Some people might also say test:watch, and it almost seems like it's composing together. Sweet, any other questions? Okay, we still have a couple of things left to do. Lunch is in about seven minutes, I'm fairly confident we can get that done.

So one other issue that we have now, we'll run the the build again,
>> Kent C Dodds: So, we look in our dist directory and actually let's go ahead and pop open the node and we'll require('/dist'). We're gonna get a big error and that error is cannot find module starwars-names.json. So this file right this index.js file is looking for a sibling, that's the relative path there, that's called starwars-names.json.

But it doesn't have one, and that's because it's in the src directory. So a couple of ways we could solve this. We could put the starwars-names.json in the root of our project and just have it look up two directories, cuz then that's relative to both of these. And that would work great, but then we'd have to make sure that we're distributing all the right files.

We'd have to call them out a lot more explicitly. I like to have my dist directory be the only thing that I send to the registry. It just makes things a lot more simple to think about, like, what am I sending to the registry? Yeah, just the dist.

So what we're gonna do is bebel has this capability to copy any files that are not JavaScript files, so we're gonna use that feature. So on this single line it will just --copy-files. And if you don't like these long name there are actually abbreviations for all of these, but I actually like doing the full version most of the time because I think it makes more sense for future maintainers.

So now if we run the build we're going to get a dist directory with starwars-names right in there. And you should be able to run node and require the dist directory, which will default to the index, and you'll get what you're looking for.
>> Kent C Dodds: And for Palpatine, [SOUND] that guy, okay, yeah.

Just taking a trip down memory lane for a second. So any other thoughts or questions, concerns, comments, jokes? Okay, we're almost there. Let's see, I haven't been watching these questions so I apologize. Mike asked a little bit ago, transpiling into a dist folder seems to be standard for all the websites I've seen.

Wait, I did read that one. Just kidding. [SOUND] We are back. Okay, so one other thing that we're gonna do here is now that we have the build working. We wanna make sure that when somebody comes into help us maintain our project and they're setting things up, we say okay install dependencies than run the validate script.

We want to make sure that not only test and linting work, but also they can build. So that we don't have something specific to our environment in those scripts. And so then to accomplish that in our validate script well just add build.
>> Kent C Dodds: And that will run in parallel.

All three of these things can run concurrently, we don't need to worry about them clashing or anything like that.

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