I am on different servers and run npm install
One server is ok. Another failed showing below error:
no matching version found for es-abstract#1.14.0
I tried npm ci. Same deal.
Then I did npm install es-abstract-1.14.0.tgz
But the size node_modules/ are different. I am using du -shc --apparent-size node_modules/ to ignore the sparse files within the folder. Why?
Could I accept that this is the network issue of the failed server？ And just keep doing this? I mean, is the installation still going to be ok in this way?
At the time that this answer was written, there are 33 release versions for es-abstract on github, but only 32 release versions are listed on its npm registry. The missing version in the registry is 1.14.0.
Perhaps on one of your servers, you had this package cached (maybe it was previously listed on the NPM registry?, or maybe from downloading it from github?), and on the other server you did not have this package cached.
I had this same error message when trying to npm install a project from github.
In my situation, the es-abstract package was not explicitly listed in the package.json file, but it was a dependency of another package. Therefore I explicitly added it with the next highest version listed on the registry, and it worked.
e.g.
"dependencies": {
"es-abstract": "1.14.1",
...
Just a guess, but maybe 1.14.0 used to be listed on the registry, but now it's not?
Related
I'm trying to run a simple hello.ts script from command line. This works if the script has no dependencies:
npx ts-node hello.ts
But as soon as I start adding some dependencies...
import _ from 'lodash';
console.log('hello');
It fails:
Cannot find module 'lodash' or its corresponding type declarations.
It keeps failing even if I install the dependencies globally. So how do I tell npx (or ts-node for that matter) to consider globally installed dependencies?
Update
Using Node 16.9.1 (upgraded via Version Lens). The error seems to have disappeared after uninstalling/reinstalling the imported libraries a few times.
If you're using npm >=1.0, you can use npm link to create a local link to a package already installed globally. (Caveat: The OS must support symlinks.)
IE: npm install -g lodash && npm link lodash
However, this doesn't come without its problems.
npm link is a development tool. It's awesome for managing packages on your local development box. But deploying with npm link is basically asking for problems, since it makes it super easy to update things without realizing it.
As an alternative, you can install the packages locally as well as globally.
For additional information, see:
https://nodejs.org/en/blog/npm/npm-1-0-link/
https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/
Are you using the n package by any chance? I used n to change from a newer version of node (16.2.0) to an older version of node (12.13.0), ran npm i and npx failed with a different error.
Using n to change back to 16.2.0 seems to have resolved the issue so I'm thinking perhaps it was an issue with package-lock.json or such
I'm sure others have this workflow, so I must be missing something here.
How does one go about developing a new version of a package, linking it to test in another app, and then installing another (unrelated) package?
What I've done:
Run git clone git#package-to-update && cd package-to-update.
Edit package, update package-to-update/package.json version to 2.0.0.
Update my-app/package.json to use package-to-update#2.0.0.
cd package-to-update && npm link && cd my-appp && npm link package-to-update.
Test out my-app, see that package-to-update#2.0.0 resolves the issue, have a small party.
Push to package-to-update's upstream, create a merge request, and wait for maintainers to merge in my changes.
Use my local, linked version in the meantime as it's required for the feature I'm working on.
Notice I need another package other-unrelated-package in my-app.
Run cd my-app && npm install other-unrelated-package.
NPM fails because it's trying to pull package-to-update#2.0.0, which is not yet published.
Cry.
Is the only option here to run the following process every time you want to npm install?
Downgrade package-to-update in my-app/package.json.
Run npm install other-package.
Run npm link package-to-update.
Upgrade package-to-update in my-app/package.json".
I generally only use npm link for development. If I want to use a local version and not have to deal with re-linking, I install it by path rather than by version.
npm install /file/path/to/your/module
Then you'll end up with a file: URL like this in your package.json:
"slug": "file:../../slug"
Subsequent npm install won't search the registry in that case. (Since it will avoid the registry on future npm install runs, it also means you need to remember to change it back to the registry when the version with your patch is released!)
I haven't tested, but this method may require that you only care about it as an immediate dependency and not a dependency of another dependency. Based on your workflow above, that seems to be the case, but mentioning it here for other folks.
How can I install a Node.js version using NODE_MODULE_VERSION 46? I keep running into a NODE_MODULE_VERSION mismatch, and recompiling hasn't helped so switching node versions might be easier.
Basically, I keep coming across this:
Warning: The module '/home/cwaugh/workspaces/myproject/build/Release/addon.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 46. This version of Node.js requires
NODE_MODULE_VERSION 57. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`). Use --force to continue.
So far, I've tried using n to change to different versions (one of my dependencies requires 4.9.1 or below), but that doesn't seem to change the NODE_MODULE_VERSION as recognized by the warning.
I've also tried recompiling:
I've tried deleting node_modules and running npm install again. (this error looks like it's coming from the project root, but it never worked for anything in the node_modules folder either)
node-gyp configure --target=4.9.1 && node-gyp build --target=4.9.1. I got the idea from here, and hoped I'd have better luck than mxcd.
node-pre-gyp rebuild. I saw this, and thought it might work for me.
This works on another, older computer running a vagrant image. Unfortunately, vagrant isn't working on the new computer either, so I've been trying from scratch. Sometimes, I wonder if it's because I'm using Ubuntu 18.04. The server's can't seem to go past 16.04 when they run our docker image.
I GOT IT!
It turns out I was getting different versions from node and nodejs
$ node --version
v4.9.1
$ nodejs --version
v8.10.0
I upgrade to node v8.10.0, redo everything, and the error's gone!
sudo npm install -g n
sudo n 8.10.0
rm -rf node_modules
npm install
node-gyp clean
node-gyp configure
node-gyp build
grunt build
grunt start
# No more NODE_MODULE_VERSION error
I tried uninstalling nodejs (since this it's been replaced by just "node"), but node-grunt-cli requires it. I'm guessing that grunt uses nodejs instead of node to check its version, causing the error. The Ubuntu repositories have Grunt v0.4.5, while Grunt stable is at v1.0.3, so it's possible a newer version of grunt would also solve this problem.
The solution didn't work for me since I had just one node version (10).
What was happening in my project, was that the package.json was pulled from the remote repository with an old version package.
At the moment of installing node modules locally (using yarn), it would download up-to-date dependencies, creating incompatibility.
After trying several solutions, what finally worked for me was picking the specific package that was giving me headache (login-funcs-nodejs) and run:yarn upgrade login-funcs-nodejs --latest
Upon executing the following command:
npm install #angular/animations#'^5.2.0' #angular/common#'^5.2.0' #angular/compiler#'^5.2.0' #angular/compiler-cli#'^5.2.0' #angular/core#'^5.2.0' #angular/forms#'^5.2.0' #angular/http#'^5.2.0' #angular/platform-browser#'^5.2.0' #angular/platform-browser-dynamic#'^5.2.0' #angular/platform-server#'^5.2.0' #angular/router#'^5.2.0' typescript#2.4.2 rxjs#'^5.5.2'
I get messages saying that no compatible version of found for rxjs. Then when I remove the specific version, it says no compatible version is found for angular/animations. Then angular/common. Etc etc.
I'm pretty sure these versions are valid, since they're the ones recommend by this Angular upgrade tool (https://angular-update-guide.firebaseapp.com/) and I can also see the "valid install target" list, which includes the versions I'm trying to install.
I know our project's dependencies are in some special repository somewhere (Artifactory, I think?) so maybe this is happening because these versions are not in the repo NPM is looking at.
Is there a way to fix this for testing purposes before committing to having to install the new versions in the repo? In other words, how do I point NPM at the NPM repo rather than the company's repo?
Well, the answer I was looking for was here:
How to specify registry while doing npm install with git remote url?
However that didn't actually work.
The problem was simply a syntax issue. After I removed all the quotes from my command so it looked like the following command, it worked
npm install #angular/animations#^5.2.0 #angular/common#^5.2.0 #angular/compiler#^5.2.0 #angular/compiler-cli#^5.2.0 #angular/core#^5.2.0 #angular/forms#^5.2.0 #angular/http#^5.2.0 #angular/platform-browser#^5.2.0 #angular/platform-browser-dynamic#^5.2.0 #angular/platform-server#^5.2.0 #angular/router#^5.2.0 typescript#2.4.2 rxjs#^5.5.2
How can I have npm tell me if all dependencies are already installed without checking the network?
My goal is to first test locally if anything needs to be installed, and then only if something is missing, I'll run a normal npm install to install it. I'm trying to avoid the initial check across the network though if everything is already there.
This is also given a package.json file with fixed versions, since obviously allowing auto upgraded packages would always require a remote repository check.
Update:
I've tested npm list which doesn't seem to access the network, and it prints out "UNMET DEPENDENCY" if something is in package.json but not installed. Is that the best way to accomplish this?
I'll probably end up with something like:
npm list | grep -c 'UNMET DEPENDENCY'
I'm not aware of anything that will explicitly tell you whether dependencies were installed from a remote repo or not. However I think that the shrinkpack package will help you achieve your aim.
Shrinkpack will cache your npm modules locally and only contact a remote repository when existing modules change or new modules are added.
I've used this in the past to reduce the number of network requests required for an npm install.