Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 833 of the free egghead.io lessons, plus get JavaScript content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Just one more step!

Check your inbox for an email from us and click link to unlock your lesson.



Introduction to How to Write an Open Source JavaScript Library

1:35 JavaScript lesson by

This is an introduction to the "How to Write a JavaScript Library" in which the scope of the series is presented. You will learn everything you need to know to create a library for JavaScript: set up the GitHub repo, publish a module to npm, set up a test suite with code coverage reporting (using Karma, Mocha, and Chai), add continuous integration, add ES6 (ES2015) with Babel, configure Webpack, and distribute the library as a "Universal JavaScript" (a.k.a. "Isomorphic JavaScript") module (consumable by both the browser and node).


egghead.io comment guidelines

Avatar
egghead.io

This is an introduction to the "How to Write a JavaScript Library" in which the scope of the series is presented. You will learn everything you need to know to create a library for JavaScript: set up the GitHub repo, publish a module to npm, set up a test suite with code coverage reporting (using Karma, Mocha, and Chai), add continuous integration, add ES6 (ES2015) with Babel, configure Webpack, and distribute the library as a "Universal JavaScript" (a.k.a. "Isomorphic JavaScript") module (consumable by both the browser and node).

Avatar
Yonatan

Again, this series is super important - both to individuals and to the community. I'm sure it will raise awareness for sharing useful pieces of code.
What I would have liked to see in this series, and is missing from the syllabus:
1) Creating a "non node.js" plugin (angualrjs maybe?).
2) Testing with Karma (as far as I can tell, it is more widely used - especially amongst angualrjs users).
3) Gulp? Grunt? Webpack? For packaging the whole deal with a "dist" library and automating stuff like tests, jsHint, etc.? (thought you avoided angular? no way! ngTemplate, ngDocs,... ;))
Are any of the above planned?

Avatar
Yonatan

Forgot to mention - bower (which would have probably made most of the former comment much shorter :)).

In reply to Yonatan
Avatar
Kent C.

Yes, yes, and yes :-) This is all planned. If you listen to the first lesson, I mention all of this and more :-) There are 10 lessons that will be published soon and I plan to record more. Thanks for the encouragement :-)

In reply to Yonatan
Avatar
Lars Rye Jeppesen

For me it was perfect. The focus was not on the code, but on the tools and processes.

Most of these processes are the same, no matter if it is a micro library or a bigtime Angular application. Of course there will be framework-specifics, but that would have derailed the course imho.

This has been (by far) the best course for me on Egghead.

In reply to Yonatan
Avatar
Kent C.

Wow Lars, that's extremely high praise! Thanks! Look forward to more to come on this series :-)

In reply to Lars Rye Jeppesen
Avatar
Florian

Thanks for this very interesting lesson, I'm currently following it thoroughly as I'm looking to open source a React library and it's so useful !

I setup a webpack / babel workflow to be able to use ES6 features. So i have a src/index.js that is the source of my library and a dist/index.js that is the transpiled ES5 version and the main entry of my package.json .

When building my library (running webpack) should I have the code minified (webpack -p or should I just leave that to users who will import my lib ?

Thanks in advance ! (Sorry if it's noobish :) )

Avatar
Kent C.

It's an excellent question. It's really up to you. I generally like to have a minified version just to make it easy for people to copy the file if they choose or even use a service like npmcdn and get a minified version.

In reply to Florian

Hello. We're going to create a micro library from start to finish, everything that we need to get this library up and running. They're a few benefits to creating a micro library in particular. First, because it's so small, it's easy to reason about the code, because there's not much there. Second, also because it's small it's really easy to test, because there's not that much code that needs to be tested anyway. Third, it's easy to re-use this code in other projects because you can simply NPM install it, and you're good to go.

There are a few drawbacks to micro libraries, though. Some people complain about how it makes managing these dependencies a little bit more tricky, because you have so many of them, it makes versioning a little bit more tricky as well. But all in all, micro libraries are a good solution for many use cases, so that's why we're building one now. Finally, even though we're technically building a micro library in this series, the principals that you learn in this series can apply to micro libraries or huge libraries alike.

Our micro library is called "Star Wars Names." We have a list of Star Wars names, about a hundred here, and we're going to enable users to call into our library, get this whole list, or get a random item from this list with a simple public API.

In this series we're going to learn how to create a Git repository, hosted on GitHub, create the library, publish it to NPM, create a full test suite for it using Karma, Mocha, and Chai, set up continuous integration, add ES6 or ES2015 using Babel, integrate webpack, and ultimately distribute this in a form that is consumable by both the browser and node. Enjoy this series.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?