The Question :
459 people think this question is useful
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?
The Question Comments :
The Answer 1
510 people think this answer is useful
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.
The Answer 2
483 people think this answer is useful
you just provide one
<folder> argument to
npm install, argument should point toward the local folder instead of the package name:
npm install /path
The Answer 3
162 people think this answer is useful
Since asked and answered by the same person, I’ll add a npm link as an alternative.
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
The Answer 4
38 people think this answer is useful
npm pack +
This is what worked for me:
STEP 1: In
module project, execute
This will build a
STEP 2: Move the file to the
Ideally you can put all such files in a
tmp folder in your
STEP 3: Refer it in your
Install the packages:
npm install or
npm i or
Now, your package would be available in your
consumer-project's node_modules folder.
The Answer 5
14 people think this answer is useful
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.
In this scenario, npm sets up
node_modules/ like this:
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 🙁
The Answer 6
4 people think this answer is useful
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:
"preinstall": "cd ../some-npm-package-angular && npm install && npm run build"
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)
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.
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:
"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:
"preinstall": "npm run clean && cd ../some-npm-package-angular && npm run package"
Reference the built tgz npm package from your main project!
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:
In the dependent package’s package.json file, then update your reference to it in the main project to reference the new filename, ex:
You get used to it. Just update the two package.json files – version then the ref to the new filename.
Hope that helps someone…
The Answer 7
3 people think this answer is useful
Missing the main property?
As previous people have answered
npm --save ../location-of-your-packages-root-directory.
../location-of-your-packages-root-directory however must have two things in order for it to work.
package.json in that directory pointed towards
main property in the
package.json must be set and working i.g.
"main": "src/index.js", if the entry file for