Creating an Open Source JavaScript Library on Github

Exercise: Creating the Code of Conduct and License.

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 "Exercise: Creating the Code of Conduct and License." 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:

In this exercise, Kent walks through creating the, LICENSE, and files. These files are written with Markdown syntax to make it easy to format them for the web. The solution to this exercise is on the FEM/01.0-important branch.


Transcript from the "Exercise: Creating the Code of Conduct and License." Lesson

>> [MUSIC]

>> Kent C. Dodds: I want you to create a code of conduct, a license, and a readme in this project. So, we'll just kinda do that together and I'll show you how I find the stuff for these files. We'll start out actually with the readme, so if you create a new file

Dot md stands for mark down and mark down is pretty much the standard format for readme files. Or pretty much any documentation files on GitHub especially. So here if you use this hash it's gonna say this is h1 and normally you would put the name of the library so we'll put starwars-names.

And then here you can put a description. When we check out the next branch all your stuff is gonna be wiped away anyway so you can put whatever you want in here. Whatever you want in here. I like Twix! Don't put that in your readme's for your libraries, I mean, you can, I guess, make it a badge, I don't know.

So yeah, readme, like I said, we'll talk about that a little bit more later. And then we'll create another new file called license. This one doesn't need to be in markdown or anything, because you're basically just gonna be copy pasting from somewhere else. And so I have a generator where I use to create all my libraries and I recommend that if you're gonna be creating a lot of the same types of projects.

Whether it be libraries or applications or something you create something like a Yeoman generator or something. To automatically like scaffold out everything for you, most of the stuff that we're gonna be talking about today, you can scaffold with a generator. But yeah, to get the license, I just go to and go to licenses and standards, licence by name, MIT.

I grab that one and copy this.
>> Kent C. Dodds: So again, that's You could also probably just Google for it and it'd be pretty simple to find. And then you can just swap out the year with the current year and copyright holders with your name.
>> Kent C. Dodds: And that is the license and then finally the code of conduct.

I make that a markdown file but that one, I'm mostly having you do this so that you can like. Not because I don't think you can do it on your own, but because I think it's helpful for you to see how I find good documentation for this kind of thing.

So there are a couple of good codes of conduct. You could probably just search open source code of conduct and find a couple of good ones. Let's see, yep, Contributor Covenant is right there at number three. The TODO Group has an open code of conduct as well. So there are a couple that you could adopt in your own projects.

I prefer the Contributor Covenant. There is a markdown version of this one, that is at And if you scroll down to the English markdown version then you can copy this and paste it in your contributor covenant. There's one place you need to update and that is in the enforcement section, there's whoops, insert email address right here.

You put your email or wherever you want to have people contact code of conduct issues so I'll say And then we've got our code of conduct. And that's it your project should look something like this now. If it doesn't, it's okay. We're gonna be checking out the next branch.

So, I should have mentioned at the beginning, we all learn differently. Some of us learn better by following along and some of us learn better by just kind of observing and then implementing later. There will be some parts of this workshop where I'll stop and let you do just work through stuff and that kind of thing.

But lots of this is setting up tooling and knowing exactly what APIs look like and stuff. So yeah, there will be a little of everything here.
>> Speaker 2: Can I ask a few questions?
>> Kent C. Dodds: Sure.
>> Speaker 2: And maybe you're going to go over this later but when we clone these, the skip, the repo that you have.

We bring in all the files that are, of course, on Github. Then if we go into that directory and run this npm setup run setup processors, it seems to remove everything from that directory.
>> Kent C. Dodds: Yeah.
>> Speaker 2: Am I seeing that right?
>> Kent C. Dodds: Yeah, so the Master branch of this project is actually a real project that's out there and published to NPM already.

So what I did was, so that we could build this thing from scratch, I branched off of master and I just deleted everything. Created the first branch and then slowly added it through the rest of the branches. So that's why you don't have anything right now.
>> Speaker 2: And then the next question, so you put up two websites that we're gonna use for our continuous integration and something else.

>> Kent C. Dodds: Yeah.
>> Speaker 2: And I can use my github account to login. Should I be working your project and then cloning it from my github account instead?
>> Kent C. Dodds: Yeah good question, we're gonna fork eventually for sure. Yep good question, that is coming. Okay sweet, any other questions? Okay, I think I'm gonna do something here with you chat folks because you're a little bit behind on this live feed.

When I am ready to accept questions or whatever, you can ask questions at any time. But when I'm waiting for questions, I'm just gonna type question mark in the chat, and you can start asking questions, if you have any. That way, we don't have to worry about the time delay with the live feed.

So Ivan is asking, I've seen so many projects with the license repeated in the heading of each source file. Is this a good practice, should it be used as default? Ivan, that's a good point, I've also seen that. I don't know enough about licenses to know whether that's required by certain licenses or if that's, yeah, if that's necessarily a good practice or not.

That's a good question to take to Google or maybe, in particular, some of the libraries that you've seen do that. I know that Web pack does this, and React does this, so you could ask them, maybe, why they're doing that. Good question and if you find out, Ivan, let us know, I'd be interested.

And Brett is asking, what is the dash f switch on the git checkout? Yeah, I forgot to mention that, so thanks Brett. Right here is how we're gonna keep up with each other. Once we're finished with this exercise, you check out this branch, and it's gonna get us all back up to the same baseline, so that nobody falls behind.

And so the -f just blows away all of your changes. I know that you're working hard on this, and it probably feels demoralizing to lose all the stuff that you've worked on. And so if you don't wanna check out branches and you wanna make sure you're following along, you can try that.

But this is a nice safety net for you, so I'm actually gonna do that right now. And, yep, still have the code of conduct, the license, and the readme, although it doesn't say I like Twix anymore, so, yeah.

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