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
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 recently updated npm to the latest version (7.1.1) using the following command:
npm i -g npm#7.1.1
It successfully installed npm 7.1.1, but when I check for global outdated packages I get this:
https://i.stack.imgur.com/3JzCS.png
How can I set the wanted version of npm to >7.0 so that I don't get this anymore in the outdated list?
Thank you.
The docs for npm outdated indicate that when running npm outdated --global, the Wanted column "shows the currently-installed version." Since it is not doing that, that would seem to be a bug in npm. Either the Wanted column should display 7.1.1 in your case or else the documentation needs to be updated to reflect the actual behavior. (I've confirmed the same behavior on my own machine, so I don't believe this is a case of user error.) I suggest opening an issue in the npm issue tracker.
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?
I just want some confirmation as I've always been using #latest for a while with my packages and want to know if I'm really installing a stable version or can possibly install a alpha/beta version of the package.
I'm pretty sure this is meant for stable versions as they tell you to install#latest for npm (unless it's special syntax like npm start).
The more I think about it, the more paranoid I get, any confirmation would be greatly appreciated. :)
Using npm install <pkg>#latest is equivalent to using npm install <pkg> by itself or listing * as the dependency version in package.json. npm documents this here:
npm install will use the latest tag by default.
So in practical terms, latest is semantically equivalent to stable.
However, if a prerelease version of a package is published to npm without specifying a prerelease tag such as --beta or --rc, that version becomes the latest by default:
By default, npm publish will tag your package with the latest tag.
As a result, it's possible to mess up and publish a prerelease version that will be installed by default. This happened to Bootstrap in late 2015.
This article from early 2016 by Mike Bostock explains how even specifying alpha or beta as part of the version number won't prevent npm from making that version the latest.
So unfortunately if you want to be certain that you get only stable versions, you need to monitor this manually or trust the package developers to always specify a prerelease tag for non-stable versions.
You can also view the tags assigned for a package like this:
$ npm view express dist-tags
{ latest: '4.16.2', rc: '4.0.0-rc4' }
This might be a stupid question but I believe I should know this since I am just starting out in the web development field rather than just assuming. I normally see this
Install via npm or bower (recommended) or manually download the package
or something of that sorts. My Assumption is that the node_module and bower_component updates the packages automatically, however I am not sure.
Sometimes I install with npm or bower, or sometimes I just mannually download the package to which I have seen no difference. Could someone please tell me why it is important to install via npm or bower so I can know for sure what is going on.
Package managers allow you to keep third party code separate from your code and have consistent versions of that code. With npm or bower you can set out exactly what dependencies you project has, and what versions through a single file, without having to bloat your codebase with the dependencies themselves.
This means that anyone who wants to set up the project can just download the core code and run npm install or the equivalent command, and install all the dependencies at the latest supported version.