Creating an Open Source JavaScript Library on Github

The Open Source Community: Getting Started

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 "The Open Source Community: Getting Started" 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 shares some slides from a previous presentation he gave about participating in the open source community. He revisits a few of the topics from earlier in the workshop about scoping the project, having a code of conduct, and stresses the importance of automation in the workflow.


Transcript from the "The Open Source Community: Getting Started" Lesson

>> [MUSIC]

>> Kent C. Dodds: So this is actually just slides from another talk. So we already talked about having a license. This is really important. And a code of conduct is really important. If we're talking about building a community, there's few things that you can do that are more important than having a code of conduct that you enforce.

For this, it's on the site of, let's see.
>> Kent C. Dodds: Yeah, so on the repo, if you just post, if you have questions after the fact, go to the Star Wars Names repo, and that's where you can chat with me about questions. Okay, so defining project scope, this is more on the side of what are you doing as a library author, not as much on the community side but on the side of building the library.

But it's important for you to communicate to your community what is this project's purpose? What's going to do? If you submit a pull request that has its feature, will I accept it? You want them to know the answer to that question before they even submit the pull request.

And so one thing to help with the finding of the scope of the project is to have file where you define what you will do, what you won't do, what you might do. So that people can look at that and realize, okay, so the scope of this project is much smaller than I'm thinking it could be.

Maybe I should just fork it or something like that. But another thing that you can do to, a problem with scoping down your project is that people are like, well, this thing can't really do anything useful for me. My use case is a little bit on the edge of this and so now I'm gonna have to fork it.

Well, something that's really impressive to me is the fact that the Redux library has done. How many people here are familiar with Redux? Heard of Redux before? So Redux is a state management library, well, it was originally created by a React developer, Dan Abramov. It's fantastic and it's less than 100 lines of code, without comments.

It really has changed the game for state management in many apps. And the reason that you can call it done or yeah, the reason it's been successful even though it's so small is because it's really extensible and a huge community is built around this library. It uses this concept called the middleware which is very similar to Express, Express uses the concept of middleware.

But, yeah, the whole idea is at any point of interest in your library's API, you can add hooks where people can say, okay, well, when you're gonna do this, I want you to call me first so I can change the arguments, for example. Or I want you to call me after this finishes, so I can go call out to something else.

And so by doing this, when people come to you and say, hey, can you implement this feature? You can say, no, you just hook into this part and you can solve your use case that way. And that way you can keep your library small and maintained much more easily and still cover the use cases that other people are looking for.

And I actually demonstrate how to do this in this YouTube video that you can check out later. My slide links are in the chat and then those slides link to these slides and then this links to the video so you can find it. I believe in you. Okay, so automating things.

So this is a blog post that talked about the case for automation, where I make the case that saving time isn't the only reason to automate workflows. One of the main reasons is to prevent you from making mistakes, like publishing before you build. And also like the context switching as well is really a big important part.

So some things you can automate. Simplify Setups. So, for all of you, when you set up this project, I could have had you run a whole bunch of scripts, but instead I said, okay, just clone this, change your directory into the repository, then run this one script. And that did everything.

And what was really cool about that was I got a whole bunch of people for this workshop and yesterday's workshop who said hey, this didn't work for me. And so I was able to update it and fix it before the workshop, but all you had to do was run three commands.

You do the same thing with your open source projects and we've done that. We have a validate script, and so you can document, hey if you want to contribute to this project, you clone this repository, cd into your cloned directory, and run this one command. You could even have a setup script.

I have a setup script in some of my projects that run both the npm install and the validate scripts. So I'm making it as simple as possible, cuz you wanna reduce barriers to entry. And here are just a couple of things that I list in there you can look at later.

So automate code quality is important. So we talked about eslint, git hooks is really useful, opt-cli we didn't talk about. So I'm gonna just pause really quickly and talk about that, opt-cli allows you to run a command if a certain file is present. And so one problem with ghooks is it adds a barrier to contributing for new contributors.

Let's say that I'm trying to add a couple of things to your library and I go to commit. And I don't follow the commit message convention. Well, everything blows up on me. And I'm like, goodness gracious, I just learned how to use git yesterday, I have no idea what this is.

And so there's a barrier to entry for people contributing to your project, especially people not experienced. And those are the ones that are excited about contributing, the most often. And so opt-cli allows you to add, kind of, you can still have shareable ghooks, but you can opt into running those ghooks.

So I recommend you give that a look and actually in the next branch I have it set up so you can take a look at that. Then code coverage, we talked about that. That's another important aspect of this, to make sure that you maintain your code quality and you automate that with code cove.

So you get that sweet code cove bot, and actually I didn't show you that, but you'll see it on your repo's. Like even if you make a pull request to your own repo then you'll see, after the build is done, the code cov bot reports what the coverage change would be.

So yeah, automating releases. We talked about semantic-release and Travis. This is awesome. It's a good thing to do.

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