In this exercise, Kent walks through creating the CODE_OF_CONDUCT.md, LICENSE, and README.md 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.
(exotic music) - I want you to create a code of conduct, a license, and a readme in this project. We'll just kind of 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, readme.md. .md stands for markdown and markdown is pretty much the standard format for readme files, or pretty much any documentation files on Github especially.
Here, if you use this hash, it's going to say this is a h one. Normally, you'd 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 going to be wiped away anyway, so you can put whatever you want in here, like whatever you want in here. I like Twix. Don't put that in your readmes for your libraries. I mean, you can, I guess. Make it a batch.
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 going to be copy pasting from somewhere else. Where I'd normally, actually I have a generator where I use to create all my libraries, and I recommend that if you're going to 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 scaffold out everything for you.
Most of the stuff that we're going to be talking about today, you can scaffold with a generator. To get the license, I just go to opensource.org, and go to licenses and standards, license by name, MIT, and grab that one, and copy this. Again, that's opensource.org/licenses/MIT.
You could also probably just google for it. It'd be pretty simple to find. Then, you can just swap out the year with the current year, and copyright holders with your name, and that is the license. Finally, the code of conduct. I make that a markdown file, but that one, I'm mostly having you do this, 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.
There are a couple of good codes of conduct. You could probably just search open source code of conduct and find a couple 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, so there is a markdown version of this one. That is at contributor-covenant.org, 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 this ... Insert email address right here. Put your email, or wherever you want to have people contact Code of Conduct issues, so I'll say firstname.lastname@example.org. Then, we've got our code of conduct. That's it; your project should look something like this now. If it doesn't, it's okay.
We're going to be checking out the next branch. 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 work through stuff and that kind of thing, but lots of this is like setting up tooling and knowing exactly what APIs look like and stuff, so there will be a little of everything here.
- [Man] Can I ask a few questions? - Sure. - [Man] Maybe you're going to go over this later, but when we clone this git repo that you have, we bring in all the files that are, of course, on GitHub, and then if we go into that directory, and run this npm setup, run the setup, run as masters, it seems seems to remove everything from that directory. - Yeah. - Am I seeing that right? - Okay. - Yeah.
The master branch of this project is actually a real project that's out there and published to npm already. 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. - [Man] Then, the next question, so you put up two websites that we're going to use for our teams creation and something else.
I can use my GitHub account to log in. Should I be forking your project and then cloning it from my GitHub account instead? - Yeah, good question. We're going to fork eventually, for sure, yep. Good question. That is coming. Okay, sweet. Any other questions? I think I'm going to do something here with you chat folks, because you're a little bit behind on this live feed. When I'm ready to accept questions or whatever, you can ask questions at any time, but when I'm waiting for questions, I'm just going to type a 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. 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 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 webpack 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. Brett is asking, "What is the -f switch on the Git checkout?" Oh yeah, I forgot to mention that, so thanks Brett. Right here is how we're going to keep up with each other, so once we're finished with this exercise, you check out this branch, and it's going to get us all back up to the same baseline, so that nobody falls behind, 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, so if you don't want to check out branches, and you want to make sure you're following along, you can try that, but this is a nice safety net for you. I'm actually going to do that right now. Still have the code of conduct, the license and the readme, although it doesn't say I like Twix anymore.
Note: This course was created by Frontend Masters. It was originally released on 08/09/2016. We're pleased to host this training in our library.
- Creating an open-source library
- Linting and testing
- Code coverage
- Installing and configuring Babel
- Peer dependencies
- Forking and renaming
- Continuous integration and automating releases