Don't reinvent the wheel. We're creating a great library here, but we don't have to write every line of code. Learn how to depend on other libraries while creating your own in this lesson.
[00:01] With our MPM configured and our PGS JSON created, we are ready to start writing this library.
[00:07] We need to create our main file for our library. We're going to create a source/index.js. I file in a source directory called index.js. This is where the main export for our library will live. When we say module to exports as common js syntax, this is the object that will be exported when people require our module.
[00:34] We're going to have two public API points on our module. First, we'll have all and then random. These properties will be used to interact with our module. The idea is that we want to have our Star Wars names exported as part of the all, and we'll have a function that you can call to get a random Star Wars name.
[00:59] I'm going to go ahead and move Star Wars names into our source directory here. We're going to require those Star Wars names to get the object that we need. We'll simply say, via Star Wars names equals require Star...Relative path Star Wars names.JSON. This will create a JavaScript object for us. We can simply assign that to the all property.
[01:28] For random we need to create a function that will get a random item from this array. This is a solved problem. Instead of taking some time to figure out how to write this properly and then making sure that I cover it with tests properly, I'm going to use a micro library that has already done this.
[01:48] We're going to say MPM install--save to save this dependency to our package JSON. Then the dependency is called "unique random array." Once that's installed it will be added as a note module right here. It will be added to our package JSON as well because we have the --save there. It's added as a dependency.
[02:14] Because we earlier configured our MPM to use save exact by default, we are saving the exact version here. We won't be surprised when somebody accidentally releases a breaking change. Let's go ahead and use this module. We'll say "/unique random array equals require unique random array."
[02:42] All that we need to do is say unique random array and pass our array. That will return us a function that we can call to get a random item from that array. If we want to manually test this really quick we can go into the node ripple. We can say var lib equals require source/index.js. Now we can say lib.all and there are all of our random names.
[03:09] We can say lib.random and invoke that over and over again, and we get a random Star Wars name every time. It looks like from our manual testing that our library is working like we want it to. We're ready to commit these changes that we have and push them up to GitHub.
[03:28] Before we do that, let's go ahead and review what we did. First, we created our index.js file that had our library in it. We moved the Star Wars names to the source directory right next to it. We brought that in. We exported it an all object, and this is what's going to be used when people require our module.
[03:48] We also created a random property. We're using a third party library to accomplish this. We installed this by saying MPM install--save unique random array. Just as a pro tip, there's a shortcut for this. We can say MPMI-S and that is the exact same as MPM install--save.
[04:08] You can also install multiple dependencies in a single command by listing the dependencies here. By adding save, it's saved our dependencies to our package JSON. We have configured our MPM to save exact by default, it's saved our dependency with the exact version, rather than having a caret or a tilde for our version.
[04:36] This protects us from surprises when somebody accidentally pushes a breaking change or does an honor sendver. That is how you create your first library.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!