This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Test npm packages locally in another project using npm link

4:01 JavaScript lesson by

We will import our newly published package into a new project locally to make sure everything is working as expected. We can do this locally before publishing with npm link. This creates a symbolic link in our node_modules folder, so our unpublished local package is used like an installed published package. This is important because it lets us test making changes to our package and using them immediately without publishing and updating a package with each change we want to test. This is good practice to do before publishing a new version of a package.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

We will import our newly published package into a new project locally to make sure everything is working as expected. We can do this locally before publishing with npm link. This creates a symbolic link in our node_modules folder, so our unpublished local package is used like an installed published package. This is important because it lets us test making changes to our package and using them immediately without publishing and updating a package with each change we want to test. This is good practice to do before publishing a new version of a package.

Here I have two terminal panes. In one of them I'm going to run MPM run dev. Now my MPM package is building when I make changes. In the other pane I'm going to check my packages.json to see what we've labeled the name of the package. This is "Sensitive Words." I'm going to copy that.

Now, let's run MPM link. In another terminal pane I'm going to create a new directory called "Some Project," and let's change directories into that directory. Now let's run MPM init with the -Y flag, which will give us our default for a package.json. Now, let's run MPM link and then paste in the name of the package that we're developing.

Now, if we take a look at our node modules folder, we see that it actually made a symbolic link for the Sensitive Words package as if we had installed it from MPM. Now we have our node modules with the symbolic link to our package locally and our package.json. Let's create a file called index.js and open that in our code editor.

Now, we can require in our Sensitive Words module. Let's create a filtered sentence. We'll use Sensitive Words. For the first argument let's say the new Apple MacBook Pro will have a touch bar. Then for the second argument let's filter out the words pro and touch bar.

Now, let's console log out filter and see what it contains. Save and close my file, and then run node on my index file. Looks like we're getting an error. It says that Sensitive Words is not a function.

Let's go back to our file and let's actually log out what we're requiring. I'll say console.log Sensitive Words. Then we'll save and close that file and then run our file again. We can see that we're actually getting an object that has a default property which contains our function.

What's happening here is if we go back into our source module and look at our source directory and then our index.js file. We're using this export default syntax, which is really just sugar for a named export called "Default." Our function here that we're exporting when it gets compiled by Babel as getting placed here inside of this default key.

We have a couple options to get this working. One is if we go back in our file. After our require we can just add a .default. Now let's get rid of this extra log. Let's save and close this file. If we run this, it should work now. We get the new Apple MacBook with the filtered words. We'll have a filtered words.

Another option is to name all of our exports. Instead of default here, we could say export const Sensitive Words is equal to our function. Now if we save that, our build reruns. If we open up our test file, we should be able to remove this default.

Instead of requiring in Sensitive Words directly, we can wrap it in the brackets. If we save and close our file, we should be able to run node index again and get the same result. Now, since we have MPM link set up, we can make changes in our source directory and test them before publishing our package.

Let's say we wanted to change our asterisk to be five asterisks sensitive three. We could go into our source directory and let's changed this three asterisks here to be five. Now if we go to our test project and run node index, we get five asterisks instead of three.

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