I'm developing two modules for NodeJS, first one named aligator and second one aligator-methods. Second one depends on first one to work. I'm developing these two modules at the same time and I want to global link aligator so I can use it like it is on npm registry and I just installed it globally. To do this NPM documentation says that I need to use npm link but it's not working.
File package.json of module aligator:
{
"name": "aligator",
"version": "0.0.1",
"description": "",
"main": "index.js",
"private": true,
"directories": {
"doc": "docs",
"example": "examples",
"test": "spec"
},
"scripts": {
"test": "gulp jasmine"
},
"license": "MIT",
"devDependencies": {
"gulp": "^3.6.2",
"gulp-jasmine": "^0.2.0",
"gulp-jshint": "^1.6.1",
"gulp-rename": "^1.2.0",
"jasmine-node": "^1.14.3"
},
"dependencies": {
"bluebird": "^1.2.4",
"lodash": "^2.4.1",
"mathjs": "^0.22.0"
}
}
File package.json of module aligator-methods:
{
"name": "aligator-methods",
"version": "0.0.1",
"description": "",
"main": "index.js",
"private": true,
"directories": {
"doc": "docs",
"example": "examples",
"test": "jasmine"
},
"scripts": {
"test": "gulp jasmine"
},
"author": "",
"license": "MIT",
"devDependencies": {
"gulp": "^3.6.2",
"gulp-jasmine": "^0.2.0",
"gulp-jshint": "^1.6.1",
"gulp-rename": "^1.2.0",
"jasmine-node": "^1.14.3"
},
"dependencies": {
"lodash": "^2.4.1",
"mathjs": "^0.22.0",
"aligator": "^0.0.1"
}
}
First of all I linked the module globally:
$ cd ~/aligator
$ npm link
/usr/local/lib/node_modules/aligator -> /Users/roc/aligator
This if I'm not mistaken has created a global reference of my module aligator and now I can use this module from everywhere I want in the computer.
Then I went to the other module and tried to install the dependency but it gave me this output:
$ cd ~/aligator-methods
$ npm install
npm ERR! 404 404 Not Found: aligator
npm ERR! 404
npm ERR! 404 'aligator' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it
npm ERR! 404 It was specified as a dependency of 'aligator-methods'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, or http url, or git url.
npm ERR! System Darwin 13.2.0
npm ERR! command "node" "/usr/local/bin/npm" "install"
npm ERR! cwd /Users/roc/aligator-methods
npm ERR! node -v v0.10.28
npm ERR! npm -v 1.4.16
npm ERR! code E404
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /Users/roc/aligator-methods/npm-debug.log
npm ERR! not ok code 0
I even tried to link it directly with:
$ cd ~/aligator-methods
$ npm link aligator
/Users/roc/aligator-methods/node_modules/aligator -> /usr/local/lib/node_modules/aligator -> /Users/roc/aligator
But it didn't work either.
Any thoughts on what it is that could be happening? I read somewhere that maybe it had something to do with my installation of node and npm because it was made by Homebrew and so sometimes I need to use sudo, it seemed unlikely but I tried what they proposed and It didn't work either.
The problem was that the main property of package.json was pointing to a non-existing file. It seems that the problem can happen due to multiple reasons so be sure to take a look at other answers.
I ran into this issue because of NVM, I was running one version of node for the dependency and another for the dependant.
Deleting package-lock.json then running npm install again resolved the issue for me.
When you first run npm link from the aligator directory, you create a link from your global node_modules directory to aligator. Then when you run the npm link aligator from the aligator-methods directory, you link aligator from your locally installed node_modules to the original source (as the output shows in your example above). Once this is done, there shouldn't be a need to install anymore since it's already "installed". What errors are you seeing after you run the npm link aligator command?
If you just want to install a dependency from a local directory, you might just try using npm install instead. For example:
$ cd ~/aligator-methods
$ npm install ../aligator
My issue ended up being that repo A was using npm and repo B was using yarn, so I needed to run yarn link in repo B in order to pull it in via npm link package-name into repo A.
What worked for me was to:
Delete the node_modules in both the dependency and the consumer module.
Run npm unlink --no-save [dependency-module]
re-link with the 2-link commands as per npm-link
Now I am able to fully test my unpublished module locally.
Additionally, there is an npm pack command which can help you test your unpublished modules, although not quite as robust.
npm-pack
Fix for my version of this issue; in npm v5.3.0, I removed node_modules from repo I was linking into another project.
I found out that after npm v3 they try to put all node_modules dependencies into one node_modules directory (one in your project) to flatten the structure as much as possible (http://codetunnel.io/npm-5-changes-to-npm-link/).
Be sure to check the main in package.json.
This serves as the entry of your package. This is a slight detail that took me a long time.
For me this happened when I decreased the version number of my local package from 0.1.0 to 0.0.1. And in the projects where I linked to this package I was still using the higher version number. Updating dependencies in package.json fixed it.
Check tsconfig moduleResolution
If like me, you happened to change the tsconfig module from es5 to esnext or something, then the moduleResolution default may have changed.
Without moduleResolution being set to "node", typescript will not resolve node_modules packages.
You can read on the Compiler Options page about how the default value depends on the value of module, whose default in turn depends on target — but probably set it to "node" explicitly.
I had a similar issue, and I had to perform the following steps to solve it:
In the library:
Setup the libraries that are generating issues as peerDependencies in the package.json instead of dependencies or devDependencies, e.g. in my case react:
"peerDependencies": {
"react": "^16.8.6",
...
}
run npm install
build the library (in my case, with a rollup -c npm script)
In my main app:
change the version of my library to point to my local project with a relative path in package.json, e.g.
"dependencies": {
"my-library": "file:../../libraries/my-library",
...
}
Add resolve.symlinks = false to my main app's webpack configuration
Add --preserve-symlinks-main and --preserve-symlinks to my package.json start script, e.g:
"scripts": {
"build": "set WEBPACK_CONFIG_FILE=all&& webpack",
"start": "set WEBPACK_CONFIG_FILE=all&& webpack && node --preserve-symlinks-main --preserve-symlinks dist/server.js",
}
run npm install
run npm run start
May be trivial, but worth mentioning:
npm link <module-name> must be executed after npm install (if needed) was executed in the <module-name> folder.
That is, unless the linked module is already present in <module-name> folder's package.json, in which case the order won't matter, because it means that the linked module is actually installed solely by npm install (as demonstrated here), and there's no need for linking using npm link - which is not the subject of this question.
The reason is that npm link <module-name> simply creates a symlink (or a folder shortcut, in Windows) to the linked package, so that executing npm install afterwards just deletes it.
To summarize, this is the order of execution:
Replacing the OP aligator with exporter and aligator-methods with importer for easier grasp
⚡ cd exporter
⚡ npm install <-- if needed, execute here, though it can also be executed after `npm link`
⚡ npm link
⚡ cd importer
⚡ npm install <-- if needed, must be executed here
⚡ npm link exporter
Bonus: A full minimal ES modules example of exporter and importer can be found here.
I know this is an old post, but in my case the issue was that I had renamed my package directory name, but the package.json "name" was still set to the old name.
for example, my directory name was package-name but the actual "name" found in package.json was package-name-b".
running yarn link would create a link called "package-name-b".
I then tried to run yarn link package-name since I was using the directory name. When I switched it to yarn link package-name-b, it worked.
I ran npm run build on the local package (dependency) and that worked for me
I was unable to import from my linked package because I simply forgot to prepend ./ to my module exports in my top level index.ts file:
export * from './utilities'
Took a while to figure that one out.
When using peerDependency
I'm developing two packages, stejs, and stejs-loader. stejs-loader has stejs as a peerDependency. When I ran npm link stejs-loader and npm link stejs in my project I was getting an error that stejs-loader couldn't find stejs. I got it fixed by running npm link stejs in the directory of stejs-loader.
Related
I created a new Laravel project with laravel new x
changed into that folder with cd x
tried installing the npm packages with npm install
This didn't work like expected.
I just got an Error: Cannot destructure property 'name' of '.for' as it is undefined.
Then I was like yeah lets just add a name to the package so I did
Ran npm install again
After that it installed something and prompted: Installed 1 Package
Instead of installing the specified devDependencies, creating a package-lock and a node_modules folder, it installed a package with the name that i just specified, globally. I knew that because of npm ls -g. So now i dont have any packages installed locally in my folder but a dependency globally that does nothing.
Output of npm ls and npm ls -g:
C:\Users\johnw\AppData\Roaming\npm
└── theNameIJustSpecified#
My package.json looks like this (and was auto-generated by the laravel installer):
{
"name": "myName",
"private": true,
"scripts": {
"dev": "vite",
"build": "vite build"
},
"devDependencies": {
"axios": "^1.1.2",
"laravel-vite-plugin": "^0.7.2",
"lodash": "^4.17.19",
"postcss": "^8.1.14",
"vite": "^4.0.0"
}
}
npm -v: 9.2.0
node -v: v19.3.0
os: windows 11
Normally this just worked out of the box with the Laravel installer. I just typed npm install and it worked.
I tried reinstalling Node and npm, even used Nvm for Windows without any change.
I tried restarting my pc without any change.
I tried creating the package.json via npm init, didn't change anything other than the output of npm ls -g (added 1.0.0 to the end):
C:\Users\johnw\AppData\Roaming\npm
└── theNameIJustSpecified#1.0.0
Edit: Tried downgrading to npm 8, also didn't work.
Downgrading to 7 works again, but I get warning because of too old version.
I checked other projects (old Laravel projects) and they have the same problem now. I used to work in them for months using npm packages for asset bundling. Now they give me the same error.
If I have a NPM 7 workspace like this:
root
- submodule0
- submodule1
- submodule2
and I navigate to the submodule0 directory and run npm i somepackage it seems to "break" the workspace by creating a new package-lock.json in the submodule0 directory and installing all the dependencies there. In other words, it just does the old behavior that existed before I created the workspace.
I was hoping for a command similar to lerna where I can install a new package in submodule0 from the root. Something like:
npm i somepackage --scope submodule0
So far, the only workaround I can find is to edit the submodule0 package.json and add the somepackage manually. Then run npm i from the root. Obviously this is not ideal because I need to look up the #latest version, navigate to the subdirectory, open the package.json, etc. etc. as opposed to just typing one line in the root.
Workspace support for npm install and npm uninstall was added in npm v7.14.0. You can now just do:
npm i somepackage --workspace=submodule0
Uninstalling modules has been the biggest pain, so this is really exciting. The npm team seems to be slowly adding support to commands one by one. Follow updates here: https://github.com/npm/cli/blob/latest/CHANGELOG.md.
I'm also baffled with why npm workspaces has been released without this functionality.
My current workaround uses the add-dependencies package, which adds dependencies to a declared package.json file, whilst skipping the installation process.
npm i add-dependencies -g
Then, from top level of the monorepo, you can run:
npx add-dependencies ./submodule0/package.json somepackage && npm i
Hopefully a --workspace argument will be added to npm i soon to avoid this faff.
Please refer to the answer of mattwad above if you have NPM v7.14.0 or above
Original answer
I wasn't quite happy with the suggestions, but combined all of them to use it in a npm script without any dependencies:
{
"add": "npm install --package-lock-only --no-package-lock --prefix",
"postadd": "npm install"
}
This can be used like following: npm run add -- submodule0 somepackage
Add only into package.json
U can use this to install package only into package.json ( you don't need external dependencies )
npm i --prefix packages/test --save --package-lock-only --no-package-lock express
followed by npm i to install specified dependency into mono repository root node_modules
Lerna
Also can use lerna to use workspace name to install dependency into
package.json
{
"name": "mono",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"wsi": "function workspaceinstall() { ( scope=$1; shift; lerna exec --scope \"$scope\" -- npm install --package-lock-only --no-package-lock \"$#\") }; workspaceinstall"
},
"author": "",
"license": "ISC",
"workspaces": {
"packages": [
"packages/**"
]
}
}
lerna.json
{
"version": "1.0.0",
"npmClient": "npm",
"packages": ["packages/**"]
}
npm run wsi [workspace name] [dependency name to install]
npm run wsi #workspace/test express
npm run wsi #workspace/test express --save-prod
npm run wsi #workspace/test #types/express --save-dev
wsi script only modify package.json for provided workspace name, to actually install dependencies u have to run npm i
In my case, which is similar to yours, I deleted all dependencies from all the inner projects, deleted also the package-lock.json, and installed everything in the root.
/
node_modules
package.json >> all dependencies
package-lock.json >> the only lock file that exists in the repo
/packages
/A
package.json >> no dependencies
-- no package-lock.json
/B
package.json >> no dependencies
-- no package-lock.json
/C
package.json >> no dependencies
-- no package-lock.json
This way, the node_modules folder ONLY resides on the root, and also the package-lock.json file is in the root.
If I allowed to have each project it's own package-lock.json I started seeing installation and runtime errors (because each project could have its own node_modules and its own version of a dependency).
This is the best way I see it works.
After trying to use the npm install with the --prefix --save --package-lock-only --no-package-lock options, npm always give the the error E404 - Not Found for my own packages of the monorepo that are not yet published to a registry. So even when trying to install external packages it fails because of my current dependencies in the package.json.
To workaround this issue I ended up with a mix of the previous suggestions:
"scripts": {
"add": "add-dependencies $npm_config_scope/package.json",
"postadd": "npm i",
},
"devDependencies": {
"add-dependencies": "^1.1.0"
},
Then I can do:
npm run add --scope=packages/app express
npm run add --scope=packages/core eslint jest -D
This works fine for installing external packages. To install my own packages that lives inside the monorepo, I still have to manually edit the package.json, otherwise I get the package not found error.
I'm using the scripts section of the package.json to force resolutions:
"preinstall": "npx npm-force-resolutions"
in the resolutions section, I have entered graceful-fs with a specified version:
"resolutions": {
"graceful-fs": "^4.2.4",
},
When i run npm i everything is installed correctly, the set versions are taken in to account. But later on when I install an additional module, e.g. npm i random-package, my set versions are being thrown away and I endup with graceful-fs#1.2.3 and other low versions in some dependencies.
If I clear the node_modules folder and run npm i again, everything is alright again.
I also tried setting the resolution more specific, like
"resolutions": {
"glob/**/graceful-fs": "^4.2.4",
},
but this doesn't help.
I also tried:
adding the module as dependency, devDependency or peerDependency
using a shrinkwrap and overriding it there
but no luck.
what am I missing?
The best solution for me to automate this was modifying preinstall script as above:
"preinstall": "npm install --package-lock-only --ignore-scripts && npx npm-force-resolutions",
Best way is to change the preinstall script to this:
"preinstall": "([ ! -f package-lock.json ] && npm install --package-lock-only --ignore-scripts --no-audit); npx npm-force-resolutions"
This will only run npm install to create your initial package-lock.json when it does not exist yet.
This is much faster than always running both (npm + npx).
As of npm 8.3.0, you can also use npm's override:
{
"overrides": {
"graceful-fs": "^4.2.4"
}
}
in the resolutions section, you must fix version
"resolutions": {
"graceful-fs": "4.2.4",
},
Hi #NthDegree the only way which worked for me was to first run the normal npm install and then add the packages-lock.json file to git. After doing that when you add "preinstall": "npx npm-force-resolutions", it always updates the dependency resolution to the version mentioned.
I am not sure if adding packages-lock.json file to git is good or bad but by using this method the CI/CD pipeline works as well.
If all of the above answers don't work and you still get sh: npm-force-resolutions: command not found
try the following:
Just change:
"preinstall": "npx npm-force-resolutions"
To:
"preinstall": "npx force-resolutions"
npx force-resolutions does not run when no package-lock.json is detected, and allows the next command inline to be executed as normal
Credit to: https://github.com/rogeriochaves/npm-force-resolutions/issues/10#issuecomment-885458937
It seems this started when I updated node/npm but I didn't realized until now when I had to delete and re create my node_modules folder.
I have a React Native project which has the core module and one Examples project to showcase the module. The examples project references the module like this in my package.json:
"dependencies": {
"module-core": "file:../core"
},
When I run npm install in the Examples project I was getting this nodule_module structure:
node_modules
core
core_dependency_1
core_dependency_2
Now, I get this:
node_modules
core
node_modules
core_dependency_1
core_dependency_2
At first I thought it had to do with peerDepencies and how npm handled flat/nested dependencies but I have checked and it seems now the core folder is now a shortcut (I am using Windows).
This is breaking my gradle scripts because some are referenced like this:
apply from: "../../node_modules/react-native-vector-icons/fonts.gradle"
I could fix this by renaming the links but that would make the build platform/environment dependent.
Also it breaks some other scripts like this one:
apply from: project(':react-native-config').projectDir.getPath() + "/dotenv.gradle"
That is because the project() resolves to my root folder and now I cannot use that either.
I am using npm 5.4.2 and node 8.8.1. Previously I had node 7.4.0.
Is there any flag or way to make npm install the localDependency and not treat it as a shortcut?
I finally found the answer. Npm Version 5 indeed changed the way the local dependencies are handled and it just makes npm link, which creates symbolic links or shortcuts in windows.
You can accomplish the same behavior as before with this:
npm install $(npm pack <folder> | tail -1)
Working for me in Windows 10 with git-bash
My final solution was having this package.json in the Example project that used the core:
{
"name": "core-examples",
"version": "0.0.0",
"private": true,
"scripts": {
"start": "node node_modules/react-native/local-cli/cli.js start",
"preinstall": "npm pack ../Core | tail -1",
},
"dependencies": {
"core": "file:core-0.0.0.tgz"
},
"jest": {
"preset": "react-native"
}
}
The preinstall script will generate the tgz file and then you can install as usual. This will avoid having to commit the tgz file to the repository.
I am testing on npm scripts to build my project dependency.
My idea comes from https://github.com/ParsePlatform/parse-server which impressed me by code in repository doesn't mean code in node_modules after npm install.
Below is my testmodule structure
src/index.js
package.json
and this is my package.json content
{
"name": "testmodule",
"version": "1.0.0",
"description": "",
"main": "lib/index.js",
"scripts": {
"build": "babel src/ -d lib/",
"prepublish": "npm run build"
},
"devDependencies": {
"babel-cli": "^6.18.0",
"babel-core": "^6.18.2"
}
}
and this is structure I expect after run npm install testmodule
node_modules/testmodule/lib/index.js
node_modules/testmodule/package.json
which is src folder should not be here.
But after I run npm install, it is exactly the same as when I push to my git repository.
Please take note that I am using GitLab in my own server.
So my questions are:
Is there anything that i'm missing to make prepublish run?
Which part of parse-server code makes the src folder and other files not there after install?
How are you running npm install?
According to the documentation on npm scripts, the prepublish script is run "BEFORE the package is published. (Also run on local npm install without any arguments.)". It seems clear that the prepublish script is only run on npm publish or npm install <local directory>.
If you are trying to install directly from your local gitlab server via a URL, this will not work - the script will not be run. The solution would be to install locally unless you're willing to open source your package & push it to the npm repository or pay for a private npm repository. This is what I have done during development of packages before they're ready to be made public.