I developed an npm module (let's call it module-x) that I regularly update and publish on the npm platform.
Software that uses this module installs it by running npm i module-x but in dependencies section of the package.json the module-x is installed with a fixed version (module-x: "1.0.0").
I'd like to use the tilde or caret version instead resulting in something like this "module-x" : "~1.0.0".
I've seen that other libraries like request can do this, but how they do it?
The prefix in the package.json file (whether ^ or ~ or none) depends on the settings of npm on the machine, which installs the package, not on your settings of the project. From your example, you, as the creator of module-x, can't enforce the users of your dependency to have it installed either module-x: "^1.0.0" or module-x: "~1.0.0". That's their choice how to install it, hence how to update it.
You could:
Ask them to manually add a prefix to your dependency
Ask them to change the global settings of npm command with npm config set save-prefix "~" (this one will result in all their installations having ~ prefix)
I have a private package on the file system that I'm trying to install in an Angular 8 project. So far with non-angular projects, this has worked fine. From the root of the Angular project I do:
npm i -S ../the-other-project-dependency/dist
The error message is:
npm ERR! Could not install from "../the-other-project-dependency/the-other-project-dependency" as it does not contain a package.json file.
The part of this that is true is that the-other-project-dependency does not contain a package.json file.
The package.json file is in ../the-other-project-dependency/dist. Specifically, it is in the dist directory.
So I'm not sure if NPM is saying that the dist directory should be named the-other-project-dependency?
I tried renaming dist to the-other-project-dependency and now it gets passed that error, but it gives an error for another private project dependency:
Specifically it says:
`the-other-project-dependency/yet-another-private-dependency` could not be installed as it does not contain a `package.json` file.
So it looks as if NPM does not understand how to work with locally installed packages. In this last case it seems as if it's saying the yet-another-private-package-dependency should be laid out as a sibling of the-other-project-dependency and it's not reading the file system path to that dependency.
I assumed per this post that using local file deps should just work.
Update
I think it's a bug in NPM. I filed a report here
Resolution
Was able to get it working using yarn, but I had to remove the local private packages and reinstall them with yarn, as yarn uses a slightly different path string for local dependencies.
I'd like to know how it works npm comparing to Maven (I come from a Java background) in terms of managing packages.
I have created a generic component using Angular 4, this component will be used in many projects. So, I have published it to our nexus registry and then, from the client projects I just import the package so that the package gets downloaded from the registry and everything works fine.
Now, for development, I don't want to be publishing to the registry every single time I do a modification in the generic component and rebuilding the clients.
I would like instead to do it like we do with Maven in Java, we install the artifact in our local repo, and the artifact will be picked up from the local repo before going to the global 'artifactory', but I see that when we install a module using npm, it gets installed inside node_modules folder inside the same project, so that the module is not available for any other project.
How should I do that? In other words, does npm keep a local repository where the installed modules are accessible to any other projects without the need of publishing to the global registry?
Thanks
use --global switch behind the npm install command to install the package of your choice global.
hope that helps
To make something available to the rest of the system's node package environment through npm, you can install it globally (which is local to your system) rather than locally (which is local to your project). You can see documentation for global-ness on installs in this part of the NPM documentation.
npm i -g package names here
npm install --global package names here
You can update your globally installed packages as you would a locally installed one as well when you need to.
npm update -g package names here
(or all of them without specifying)
npm update -g
See the full NPM documentation pages for more detailed flags, etc.
If you're hoping to use your own packages in a managed environment, you can either publish them as private modules or keep them in a VCS (mostly git) and reference them by the appropriate method for that VCS in your projects' package.json scheme through the dependencies block for github urls or more generally other git hosts, like
"dependencies": {
"myComponent": "user/repo#feature\/branch",
"otherComponent": "git+https://myGitHost.tld/.../projectName.git#commit"
}
How do I setup a .npmrc file inside my project where I can define my own private registry? I don't want to have this kind of configuration in my user config .npmrc. Every other developer should be able to just git clone the project and run npm install.
This is what I have so far:
// .npmrc
registry=https://npm.fury.io/AUTH_TOKEN/me/
// package.json:
{
"name": "webapp",
"description": "",
"version": "1.0.0",
"private": true,
"dependencies": {
"jquery": "1.2.3",
"myPrivateLibFromNpmFury": "0.0.4"
}
}
npm install myPrivateLibFromNpmFury
returns
npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/myPrivateLibFromNpmFury
As it was pointed out by #Paulpro and #Alexey B. the most parts of it worked already, but I couldn't see it right away, maybe because I didn't reload my bash environment properly. But after that I faced other issue with npm outdated that was caused by the registry url. It turns out npm can only have one registry url, (which is pretty crazy) and if you want to use private and public npm-modules you have to proxy the public npm-module registry through your private registry. Luckily fury.io supports that, so in my case instead of using this:
//.npmrc
registry=https://npm.fury.io/AUTH_TOKEN/me/
i have to use this:
//.npmrc
registry=https://npm-proxy.fury.io/AUTH_TOKEN/USER_NAME/
UPDATE:
It is possible to work around the problem (npm is tied to only one registry). First you have to add a scope to all of your private packages.
Now with .npmrc you can link the registries for the scopes, and you no longer need any proxies at all.
//.npmrc
#project_a:registry=https://npm.fury.io/AUTH_TOKEN/USER_NAME/
#project_b:registry=https://npm.fury.io/AUTH_TOKEN/USER_NAME/
#company_a:registry=https://npm.fury.io/AUTH_TOKEN/USER_NAME/
Noticed to the docs
Per-project config file
When working locally in a project, a .npmrc file in the root of the
project (ie, a sibling of node_modules and package.json) will set
config values specific to this project.
Note that this only applies to the root of the project that you're
running npm in. It has no effect when your module is published. For
example, you can't publish a module that forces itself to install
globally, or in a different location.
I tried to create the files you specified in the question(package.json and .npmrc), everything working fine. Maybe you made a typo somewhere?
frgt$ npm i myPrivateLibFromNpmFury --verbose
npm info using npm#3.3.12
npm info using node#v5.1.1
npm verb request uri https://npm.fury.io/AUTH_TOKEN/me/myPrivateLibFromNpmFury
npm verb request no auth needed
npm info attempt registry request try #1 at 14:36:10
npm verb request id 23f09acc4e7021c7
npm http request GET https://npm.fury.io/AUTH_TOKEN/me/myPrivateLibFromNpmFury
npm http 403 https://npm.fury.io/AUTH_TOKEN/me/myPrivateLibFromNpmFury
You should use the seamless proxy:
registry=https://npm-proxy.fury.io/AUTH_TOKEN/me/
Creating custom npm config for the project
You can create .npmrc file in your project folder, creating .npmrc file override
the default .npmrc which is located in C:\Users\username\.npmrc (it will work as global variable)
# for custom package from your companies artifactory
#myscope:registry=https://mycustomregistry.example.org
# if you want to override with default
registry=https://registry.npmjs.com/
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?
you just provide one <folder> argument to npm install, argument should point toward the local folder instead of the package name:
npm install /path
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.
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"
}
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...
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 :(
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.
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 ../location-of-your-packages-root-directory is ../location-of-your-packages-root-directory/src/index.js
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...
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.
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>
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...)