679

I have a downloaded module repo, I want to install it locally, not globally in another directory?

What is an easy way to do this?

11 Answers 11

757

you just provide one <folder> argument to npm install, argument should point toward the local folder instead of the package name:

npm install /path
19
  • 7
    Unlike link, this uses .npmignore. Commented Jul 7, 2017 at 13:35
  • 52
    @bithavoc At least as of npm 5, installing a folder now creates a symlink, not a copy. See docs.npmjs.com/cli/install
    – Frank Tan
    Commented Oct 19, 2017 at 13:59
  • 12
    I tried to use this way, but my module can't find it's peerDependencies. Commented Jun 4, 2018 at 20:35
  • 4
    it's nice to rm -rf node_modules before and npm install after you run the answer's script. Commented Jul 2, 2018 at 15:00
  • 15
    @FrankTan Yes, but how to get the old behavior? I want the copy!
    – Michael
    Commented Sep 9, 2019 at 2:43
605

From the npm-link documentation:

In the local module directory:

$ cd ./package-dir
$ npm link

In the directory of the project to use the module:

$ cd ./project-dir
$ npm link package-name

Or in one go using relative paths:

$ cd ./project-dir
$ npm link ../package-dir

This is equivalent to using two commands above under the hood.

13
  • 26
    This is the only sane looking approach I've seen so far - why npm has to be so obscure/obtuse w. regards to creating a local package, installing it and then using it, I don't know... link works, (and its great), but the terminology is rather confusing.
    – smaudet
    Commented Dec 25, 2015 at 22:22
  • 6
    @Rich Apodaca, thanks for the doc link. It doesn't mention undoing the process. It looks like all it does is create symlinks, so I can remove those as normal? Commented Jan 12, 2016 at 17:51
  • 1
    @TylerCollier npm unlink appears to be the mirror-image operation stackoverflow.com/a/24940024/54426 Commented Oct 25, 2016 at 15:36
  • 1
    Just a note, if you use Angular2 (or maybe other applications?), there is some buzz around npm linking being root cause of specific kind of issue. Example here and here Commented Apr 20, 2017 at 23:03
  • 6
    However keep in mind that npm link will create a second instance of external dependencies. So if you have a package A need B and C, B need C. linking B will cause application A to have two instances of C. Commented Jun 22, 2017 at 6:46
215

Since asked and answered by the same person, I'll add a npm link as an alternative.

from docs:

This is handy for installing your own stuff, so that you can work on it and test it iteratively without having to continually rebuild.

cd ~/projects/node-bloggy  # go into the dir of your main project
npm link ../node-redis     # link the dir of your dependency

[Edit] As of NPM 2.0, you can declare local dependencies in package.json

"dependencies": {
    "bar": "file:../foo/bar"
  }
7
  • 32
    It might not be original intent of the question, but it's probably what most people who find this through google want.
    – Dusty J
    Commented Aug 11, 2013 at 16:32
  • 2
    This answer seems incomplete, you need to run npm link against the folder once (to create a global symlink) and then run npm link package-name within the folder of the project (to use the global symlink in your project). The answer below is the right answer. Commented Oct 4, 2014 at 19:12
  • 10
    @ThomasPotaire both answers are correct. If you look at the npm link documentation, it presents both methods, with this relative directory approach as a shorthand. Commented Nov 29, 2014 at 19:26
  • 2
    The second method (using the file: approach) allowed for my app and the local module to share a dependency. My test of npm link resulted in a duplicate dependency, which breaks things if the dependency needs to be used as a singleton. Commented Jan 30, 2017 at 4:25
  • 1
    To add the local dependency without editing the package.json file manually you can run npm install with the local path: npm install ../foo/bar --save updates the packages.json file the same way.
    – mlhDev
    Commented Jul 7, 2022 at 14:26
154

npm pack + package.json

This is what worked for me:

STEP 1: In module project, execute npm pack:

This will build a <package-name>-<version>.tar.gz file.

STEP 2: Move the file to the consumer project

Ideally you can put all such files in a tmp folder in your consumer-project root:

STEP 3: Refer it in your package.json:

"dependencies": {
  "my-package": "file:/./tmp/my-package-1.3.3.tar.gz"
}

STEP 4: Install the packages:

npm install or npm i or yarn

Now, your package would be available in your consumer-project's node_modules folder.

Good Luck...

6
  • 1
    I forgot to build my package before packing, so npm run build before.
    – Misi
    Commented Sep 18, 2020 at 19:05
  • 2
    This is the best reply because it also install sub-dependencies! Commented Jun 20, 2021 at 1:11
  • 1
    Yeah, if you use file:<package_root_path> (not the path of the pack file) in the dependencies to install the package from your local file system. The local package will not be copied to your node_modules but instead it is linked into node_modules. With npm i, sub-dependencies can be installed automatically but the sub-dependencies cannot be shared with other packages. In this situation, the instanceof keyword may not work as expected if you want to use the keyword for the objects from the local project. So, I think npm pack + package.json is a reasonable solution. Commented Sep 27, 2021 at 16:15
  • 1
    PSA: Yarn struggles with this method due to overzealous caching. See yarnpkg/yarn#2165. I had to migrate my project (back) from Yarn to NPM for this. Commented May 13, 2022 at 4:30
  • Pls add one more step to it at the beginning. Otherwise pack cmd wont work npm run build
    – rahulxyz
    Commented Oct 13, 2023 at 12:49
24

Neither of these approaches (npm link or package.json file dependency) work if the local module has peer dependencies that you only want to install in your project's scope.

For example:

/local/mymodule/package.json

"name": "mymodule",
"peerDependencies":
{
  "foo": "^2.5"
}

/dev/myproject/package.json

"dependencies":
{
  "mymodule": "file:/local/mymodule",
  "foo": "^2.5"
}

In this scenario, npm sets up myproject's node_modules/ like this:

/dev/myproject/node_modules/
 ↳ foo/
 ↳ mymodule -> /local/mymodule

When node loads mymodule and it does require('foo'), node resolves the mymodule symlink, and then only looks in /local/mymodule/node_modules/ (and its ancestors) for foo, which it doen't find. Instead, we want node to look in /local/myproject/node_modules/, since that's where were running our project from, and where foo is installed.

So, we either need a way to tell node to not resolve this symlink when looking for foo, or we need a way to tell npm to install a copy of mymodule when the file dependency syntax is used in package.json. I haven't found a way to do either, unfortunately :(

3
  • I found a workaround, which is to set NODE_PATH to point to the node_modules/ where foo is installed. So for the above case, it would be this: NODE_PATH=/dev/myproject/node_modules/ That allows mymodule to find foo. Commented Nov 8, 2018 at 20:32
  • There's a solution for. Put the dependency modules in project root folder. Define your dependencies in package.json with the usual 'file:' prefix. Do npm i This will create a symlink in project's node_modules as well as its dependencies may be hoisted to the toplevel node_modules as they would for other types of dependencies. My npm version is v6.14.4 . After spending couple of hours on how to fix this, found this solution here : (atmos.washington.edu/~nbren12/reports/journal/…) . Thanks nbren12. Commented Apr 22, 2020 at 13:22
  • 1
    I was having the same trouble. I found this answer: stackoverflow.com/questions/50807329/…, this solves my problem with peer dependencies and local libraries.
    – theawless
    Commented Apr 26, 2020 at 16:04
17

Missing the main property?

As previous people have answered npm i --save ../location-of-your-packages-root-directory. The ../location-of-your-packages-root-directory however must have two things in order for it to work.

  1. package.json in that directory pointed towards

  2. main property in the package.json must be set and working i.g. "main": "src/index.js", if the entry file for ../location-of-your-packages-root-directory is ../location-of-your-packages-root-directory/src/index.js

2
  • 2
    npm --save? You mean npm i --save? (Which is now equivalent to npm i) Commented Jul 9, 2021 at 15:02
  • When working with nx workspaces this is what solved the issue of local modules not being found. Commented May 9, 2022 at 14:09
16

So I had a lot of problems with all of the solutions mentioned so far...

I have a local package that I want to always reference (rather than npm link) because it won't be used outside of this project (for now) and also won't be uploaded to an npm repository for wide use as of yet.

I also need it to work on Windows AND Unix, so sym-links aren't ideal.

Pointing to the tar.gz result of (npm package) works for the dependent npm package folder, however this causes issues with the npm cache if you want to update the package. It doesn't always pull in the new one from the referenced npm package when you update it, even if you blow away node_modules and re-do your npm-install for your main project.

so.. This is what worked well for me!

Main Project's Package.json File Snippet:

  "name": "main-project-name",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    ...
    "preinstall": "cd ../some-npm-package-angular && npm install && npm run build"
  },
  "private": true,
  "dependencies": {
    ...
    "@com/some-npm-package-angular": "file:../some-npm-package-angular/dist",
    ...
  }

This achieves 3 things:

  • Avoids the common error (at least with angular npm projects) "index.ts is not part of the compilation." - as it points to the built (dist) folder.
  • Adds a preinstall step to build the referenced npm client package to make sure the dist folder of our dependent package is built.
  • Avoids issues where referencing a tar.gz file locally may be cached by npm and not updated in the main project without lots of cleaning/troubleshooting/re-building/re-installing.

I hope this is clear, and helps someone out.

The tar.gz approach also sort of works..

npm install (file path) also sort of works.

This was all based off of a generated client from an openapi spec that we wanted to keep in a separate location (rather than using copy-pasta for individual files)

====== UPDATE: ======

There are additional errors with a regular development flow with the above solution, as npm's versioning scheme with local files is absolutely terrible. If your dependent package changes frequently, this whole scheme breaks because npm will cache your last version of the project and then blow up when the SHA hash doesn't match anymore with what was saved in your package-lock.json file, among other issues.

As a result, I recommend using the *.tgz approach with a version update for each change. This works by doing three things.

First:

For your dependent package, use the npm library "ng-packagr". This is automatically added to auto-generated client packages created by the angular-typescript code generator for OpenAPI 3.0.

As a result the project that I'm referencing has a "scripts" section within package.json that looks like this:

  "scripts": {
    "build": "ng-packagr -p ng-package.json",
    "package": "npm install && npm run build && cd dist && npm pack"
  },

And the project referencing this other project adds a pre-install step to make sure the dependent project is up to date and rebuilt before building itself:

  "scripts": {
    "preinstall": "npm run clean && cd ../some-npm-package-angular && npm run package"
  },

Second

Reference the built tgz npm package from your main project!

  "dependencies": {
    "@com/some-npm-package-angular": "file:../some-npm-package-angular/dist/some-npm-package-angular-<packageVersion>.tgz",
    ...
  }

Third

Update the dependent package's version EVERY TIME you update the dependent package. You'll also have to update the version in the main project.

If you do not do this, NPM will choke and use a cached version and explode when the SHA hash doesn't match. NPM versions file-based packages based on the filename changing. It won't check the package itself for an updated version in package.json, and the NPM team stated that they will not fix this, but people keep raising the issue: https://github.com/microsoft/WSL/issues/348

for now, just update the:

"version": "1.0.0-build5",

In the dependent package's package.json file, then update your reference to it in the main project to reference the new filename, ex:

"dependencies": {
       "@com/some-npm-package-angular": "file:../some-npm-package-angular/dist/some-npm-package-angular-1.0.0-build5.tgz",
        ...
}

You get used to it. Just update the two package.json files - version then the ref to the new filename.

Hope that helps someone...

5

I came across different solution than above while installing custom build package for CKEditor5.

So I uploaded package to app root directory, than:

npm add file:./ckeditor5

In my package.json package is listed as a file:

"ckeditor5-custom-build": "file:ckeditor5",

I think this answer could be relevant to the topic on how to add local package.

1
  • 1
    Hi Simon Klimek. This solution works for me to map to a local NPM module. But If i do any changes to the module, i have to re-install it again using npm add file:./ckeditor5 command. Is there any way to overcome this problem so that whenever i do any changes locally, they should be automatically reflected without re installing? Commented Nov 24, 2022 at 5:13
3

As explained in the accepted answer by @fancy, you can use this command:

npm install ...<path_to_your_local_package>

to add your local packages.

In the package.json of your project it will create an entry like:

"dependencies": {
    ...
    "your_package_name": "file:...<path_to_your_local_package>"
    ...
}

If the package you're including is within the project root, then it will do an installation of all the dependencies of your included local package. Otherwise, i.e. if it's outside your project root, it will simply create a symbolic link (as @frank-tan pointed out), in which case, if for some reason you've deleted the node_modules directory in your project or you need to do a fresh reinstall you must run:

npm install --install-links

The command line option install-links ensures that all dependencies of the local packages get installed automatically. This will come in handy if, for example, you're using Jenkins and need to deploy a large project with many custom-developed nested dependencies.

See official npm-install documentation for more detail: https://docs.npmjs.com/cli/v9/commands/npm-install

1

For installing local module / package, that not yet on npm or you are developing an npm package and want to test it locally before publishing it. You can try this -

npm i yalc -g

Go to the module/package folder then -

yalc publish

Your packakge is ready to use, now go the project you want to install it -

yalc add <Your package name>

Package will be installed to you project. If you want to remove it -

yalc remove <Your package name>
-1

For more recent versions of npm (I'm using 8.1.3 under macOS Big Sur), the sequence of commands is even easier...

cd /path-where-your-local-project-is/
npm init

This will ask you for some data related to your project and properly initialises your project.json file.

Once that is done, you can install additional modules with:

cd /path-where-your-local-project-is/
npm install --save-dev some-npm-module .

That's all you need!

Note: I believe that the trailing dot is not necessary if you're inside the project directory, but I also think that it doesn't hurt to add it :-)

(I wonder why the official docs still don't explain this...)

4
  • I did a few tests, and, indeed, it seems to work without the dot for designating the current directory, when you're already inside it. Commented Feb 10, 2022 at 9:05
  • 1
    How do you install local modules with this? This answer doesn't make sense to me. Commented May 8, 2022 at 3:41
  • This doesn't install a local module at all Commented Jan 11, 2023 at 23:26
  • Shouldn't the second directory be something of the form cd /path-where-you-want-to-install-your-local-project? Then, install it as you describe. Commented May 16, 2023 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.