When I run npm install, all regular dependencies are installed. However, dev-dependencies aren't. As I understand it, by default, both should be installed. I haven't changed my NODE_ENV, and I've never had this issue before. However, it started after this completely wiping computer's drives and freshly installing Windows.
Related
I have been using NPM exclusively for my projects and was assigned another project that requires using Yarn. I need to have support for both and will frequently switch back and forth on projects.
Are there any known issues with installing yarn globally and still using NPM on other projects?
super awesome, there are no such conflicts using yarn and npm together.
because yarn and npm both have different installation directories.
for global packages, you can use both, but don't forget to stick to one. we use yarn for our production.
for non-global packages, it is beneficial to stick to what the project author uses.
it becomes difficult sometimes if you have yarn.lock and package.lock file together, because there is a risk of being out of sync. for example, someone updated one package using yarn, someone will not get that changes who use npm and so on.
Yarn and npm are interchangeable. As long as you use the same one each time, there is no difference between them. They have different install directories, which is why they can't be used together. Yarn will install a package, npm can't find it. npm will install a package, yarn can't find it.
it is a more beneficial and good habit to use one package for each project to make sure that all packages are installed correctly, Having half your packages installed with yarn will stop npm start from working; having half your packages installed with npm will stop yarn start from working.
also always use the same one for global too, it does not matter what you use yarn or npm. it does not matter to your global install.
In a vue project, that is worked on by a lot of people a recently started to get this error when running:
npm run dev
error when starting development server
When running npm install, I also get this warning which might be related to the problem:
npm WARN bootstrap#4.5.0 requires a peer of popper.js#^1.16.0 but none is installed. You must install peer dependencies yourself.
I believe this is happening since I updated my node version, but I'm not sure.
From my research this problem might be related to node-sass or the css-loader.
Details:
Windows 10 64bit
node version: 12.16.3
npm version: 6.14.4
What I've already tried
Completely uninstall node and reinstall it
Try different node versions with nvm (I always deleted node_modules and package.lock and ran npm install again)
Completely delete my git repository and start fresh
Delete node_modules and run "npm ci"
install the css loader
Other development environments work fine so it's most likely something specific with this repository and my machine but I don't really know how to find the problem.
And also, the environment was working fine for me a couple of days ago so it's not a general problem in this repository.
I just setup a test, and tried to npm install express even though express already exists globally on my system. To my surprise, instead of using the global version, it ended up re-installing a version locally!? Isn't it supposed to use the global version... Or am I suppose to use -g every time, even when I only want to use the existing global version. Otherwise, what's the point of installing anything locally!?
The answer is "NO". It isn't supposed to use your global version.
If you want to use your global version, then you doesn't need to execute npm install at all because it is already installed.
If you do it then, obviously, you are saying "I want to install it locally to my project". And more than that: "I want to install its latest version unless it is declared in my package.json with other explicitly specified version".
In fact, the actual question is: Why in the hell would you want to not install a dependency of your project locally? To have more version mismatch issues?
As #anshuman_singh says, best practice is to always do an npm install --save.
You are able to use globally installed packages, of course. It could be handy for fast testing code that you will drop just after a few hours or so.
But, anyway: If you doesn't have really hard disk or network bandwidth issues, installing all dependencies locally will avoid you too much trouble in the future.
On the other hand, uploading that modules to your code repository is also a bad idea (maybe that is what you were trying to avoid) because, with different versions of node, most native modules won't work if not rebuild. But most VCS support ignoring files and or directories that must not be uploaded.
For example, in git (.gitignore file):
**/node_modules
In summary:
npm init (if you didn't already it).
npm install --save for all your project dependencies.
npm install --save-dev for dependencies not needed in production (testing stuff).
Don't upload node_modules to your VCS.
After new checkout: npm install or npm install --production (to not install dev-dependencies).
npm install -g only for tools you will use in console.
This way, you are sure that you will have in production (or other dev environments) the exact same version of each package.
And, finally, if you ever want to upgrade some package to its latest version, simply run:
npm install --save <pagkage_name>#latest.
If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.
If you’re installing something that you want to use in your shell, on the command line or something, install it globally, so that its binaries end up in your PATH environment variable.
The first option is the best in my opinion. Simple, clear, explicit. The second is really handy if you are going to re-use the same library in a bunch of different projects
Install locally-
npm install moduleName
install locally and save in package.json-
npm install moduleName --save
install globally-
npm install moduleName -g
According to Heroku I should avoid global dependencies when asking Heroku to build my project. But I still want Bower and Grunt on the command line.
My question is: how then should I be running these tools?
Rather than installing them with npm install -g, should I be adding paths from node_modules to PATH, or the like? (Ubuntu)
If Grunt/Bower are installed globally on development machines -say when someone new starts on the project -then presumably npm install -g grunt-cli might give a different Grunt version to what's in package.json. Hence what Heroku runs and what developers run might accidentally differ.
(Or is that unlikely to be a problem?)
The best practice is to keep everything local, with npm install --save.
That way you can align versions for everyone in the team simply by tweaking the package.json file.
If you only need Bower and Grunt etc. to be available in your dev environments, then install them with npm install --save-dev. This will cause them to be saved in a devDependencies section in your package.json. Dependencies referenced therein will not get distributed to production (e.g. Heroku), but will be available in all your dev environments.
If you really do need Bower and Grunt etc. to be available on Heroku, then install them with npm install --save.
At any rate, npm should automatically save symbolic links to your executables (e.g. grunt-cli) in directory node_modules/.bin, and should take care of adding node_modules/.bin to your PATH, so you don't have to worry about that.
I have a Linux server that runs some virtual Machines using KVM. Host machine is a Debian derivate with kernel 2.6.32-32(-pve).
In roughly 75% of the times I run npm install, it hangs while installing modules. I ran it in silly debug level and it always hangs at the line
npm info postinstall [module name] (older npm versions)
or
npm verb unlock done using [...] (newer npm versions)
forever.
It happens in every project on the host machine and on the virtualized systems for every node and every npm version I have tested (a lot, including the newest ones (2.7.x atm)).
It also is not deterministic. Sometimes it works, sometimes not and most of the times it hangs on a different module.
On my dev machine (which is in the same network, running OS X 10.10) it works fine.
I am not behind any kind of proxy.
What could possibly be wrong here?
EDIT: For the time being I solved this problem by checking in all my dependencies as gzipped files using https://github.com/JamieMason/shrinkpack
I was having the same issue for several hours, and couldn't work out what the problem was. I tried re-installing everything a few times, manually installing individual modules, switching from x64 to x86 versions of NodeJS, etc, and got nowhere.
In the end, I changed networks, from WiFi over ADSL2+ [~2mbps] to 4G Hotspot [~20mbps] and it worked in 30 seconds. No idea why, since it didn't seem like a network speed issue, but it solved the problem.
Hope this helps someone else, too!
I had the same problem on our Jenkins slaves based on Ubuntu, and it was solved by upgrading npm.
Default npm installed by apt-get has version 1.3.10 now, which is very old (shown by npm --version). There are at least two ways to upgrade it:
Run sudo npm install -g npm command. If you want to install a specific version you can run append it at the end of command: sudo npm install -g npm#2.1.3.
Or you could add NodeSource repositories using these instructions and run usual sudo apt-get update.
I have the same problem on Windows. I deleted my npm-cache folder and reinstalled npm. Everything started working normally after that.
The npm-cache folder can be found at
<your-drive>\Users\<your-name>\AppData\Roaming\npm-cache
Remember to turn on 'View hidden files because the AppData folder by default is hidden
You can reinstall npm by using the command,
npm i npm -g
On Windows make sure you are in a native CMD (not in VSCODE or whatever IDE). Also, try increasing the max memory limit for node:
set NODE_OPTIONS=--max_old_space_size=8096
I did the same, switched my network from WiFi to 3G and it worked.
I'm experiencing the same problem, this is the issue on Github:
https://github.com/npm/npm/issues/7862
There are some useful tips that seemed to help a few people.
For me doing $ npm install -g node-gyp (as suggested here: http://gangmax.me/blog/2013/05/13/resolve-npm-update-node-gyp-hung-problem/) fixed the problem.
I had the same problem and just run
npm cache clean
And it works!
Had this same problem in Windows. The solution was to restart after installing node and npm and then run command prompt as administrator.
In my case, a system restart did the work.
I ran npm install --verbose which suggested some lock on a file in npm-cache. And I think the system released the file (which was under use) after the system restart. I am using windows.
Try cloning the project again and then run npm install to install the packages in your terminal.
I ran into this with npm v6, and it turned out I was just being impatient. I just needed to wait a little longer and it proceeded to the next step.
npm cache clean --force
works for me :)
=> this method working with me When npm block in installation Package for IONIC installation and ReactNative and another package npm.
you can change temporary :
npm config set prefix C:\Users[username]\AppData\Roaming\npm\node_modules2
change the Path in Environment Variables set C:\Users[username]\AppData\Roaming\npm\node_modules2
Run the your command to install your package .
open file explorer copy the link C:\Users[username]\AppData\Roaming\npm\node_modules
ok file yourpackage.CMD created another folder Created "node_modules2" in node_modules and contain your package folder.
copy your package file CMD to parent folder "npm"
copy your package folder to parent folder "node_modules"
now run npm config set prefix C:\Users[username]\AppData\Roaming\npm
change the Path in Environment Variables set C:\Users[username]\AppData\Roaming\npm
now package working correctly with Command line