I'm having an issue with resolving a warning highlighted by npm audit. I followed the path to the dependent package which had the issue and ran the suggested fix command to update the dependency package that was causing the issue.
The path looks like this: npm/node_modules/npm-profile/node_modules/make-fetch-happen
Now when I run npm audit in the make-fetch-happen folder there are no errors, and the same happens with npm-profile and npm. But when I go back up one level to the package containing npm the audit still highlights the original issue as though it hasn't been resolved.
I am new to using npm so I'm not sure how the file structure works or what effect it has running commands like this at different levels of the file structure.
Is there a command I can run to make the higher level package acknowledge the fix that was run at the lower level?
Sometimes this bug occurs because the package-lock.json is buggy. If you look for the leveraged library within your package-lock. You should see it by searching for the package name and look to see if there are any with an outdated version number. Chances are there will be. I found being on npm#6.1 deleting both the node_modules and the lock file and npm installing fixed the issue. But sometimes it may not work.
Related
I keep getting this issue:
[snip of my issue][1]
I'm teaching myself node and am trying to make a CRUD RESTful application in my spare time. I'm working off this book:
https://leanpub.com/mean-machine.
For the past 3 days I've been stuck with this issue. It is specifically concerning the bcrypt-node.js . It's job is to hash passwords. Some things I have tried.
Downloaded python 3.5 as I got errors saying the runtime was needed to execute.
Setting python environment variable in PATH
npm uninstall and install.
Tried creating a new project, same issues cropped up.
npm clear cache
Since it is an old version of the bcrypt-node.js module changed the version in package.json from "0.0.3" to "0.0.5". I thought it could be a bug. Unlikely as that is.
I'm very new to node.js so I feel like I'm doing something silly that I just cannot see. Also I don't understand a lot of the information the command line is providing me. Thank you in advance.
EDIT 1:
Picture of my code.
Edit. (For future visitors) I needed to pay more attention to the various dependencies and a further understanding of JS in general to utitlise the power of Node.js, which is something I didn't do. Also recommended is a good understanding of Express.
A deeper understand of the npm is needed.
I found a fix through trial and error and some googling.
In case any one looks up this again in the future I entered:
npm install node-gyp -g && npm cache clean && rm -rf node_modules && npm installinto the command line and it appeared to fix the issue when I ran nodemon server.js
Fingers crossed it does not crop up again.
If someone would like to explain to me what exactly was the problem I had I would really appreciate it. I have a feeling a module or dependency wasn't installed correctly?
EDIT 1. Furthermore configure the PATH in your environment variables.
ie I created a path for python in the command line
PATH python = C:\Python27\python.exe & another PATH for MongoDB
i.e C:\Program Files\MongoDB\Server\3.2\bin
My code is :
http://pastebin.com/rCy4wSUK
As soon as this function is called by router it prints
"done copying contents of clean base into temp" and then error which is here:
http://pastebin.com/UxEu4PaS
So at least it is not giving an error in copying but what is causing it to throw this error.
Sounds like the fs.extra module has not installed completely and is missing a dependency. Your code runs fine for me with a fresh npm install fs.extra q
Remove your node_modules folder and re-run npm install (if your dependencies are listed in package.json) or npm install fs.extra q (if they are not).
I've seen this issue on case-insensitive filesystems in projects that require different versions of walk that depend on forEachAsync#2.x and foreachasync#3.x. Because the casing but not name of foreachasync changed across versions, it seems like it might be confusing npm and not properly installing the right versions.
I was able to fix this in our project by explicitly depending on foreachasync#^3.0.0.
My current npm version is 3.7.3 . Previously, only the required packages were getting installed in my node modules. But right now they have all flattened and have 100 + folders visible when I look into node modules. I prefer the older way where you could go into individual folders and see their dependencies.
here is a similar thread:
Why does npm install many packages into "/node_modules" instead of only one?
I tried running npm uninstall without much success.
Basically, you are out of luck... NPM does not provide any configuration options regarding this. It will nest dependencies if it must in order to resolve version conflicts, but only in this case. Your only option is to downgrade NPM (not recommended). However, if you just need to see the dependencies nested for informational reasons, you can use npm ls. It will draw you a graph.
See this relevant NPM issue for more discussion: https://github.com/npm/npm/issues/9809
Now that node js' LTS doesn't include an NPMv2 I found myself stuck with this issue again.
For those of you also caught out, the link that #KevinBurdett mentioned, also has some answers.
You can force downgrade npm using npm itself (using sudo or equivalent for this). From https://github.com/npm/npm/issues/9809#issuecomment-179702479:
as root I simply do npm install -g 'npm#<3' on my system every time I
a new version of Node comes out; your mileage might vary, but it's
fairly trivial to "downgrade" :-)
Another alternative is to use the Node Version Manager (NVM): https://github.com/creationix/nvm. Your mileage may vary depending upon personal config/preferences/platform.
That said, npm 3 and the issue of flat dependency trees will be with us from hereafter... It's probably high time to start accepting that change.
My personal grudge with this is that it makes the node_modules folder incredibly difficult to work with in an IDE, especially when you need to look at the implementation of your immediate dependent modules, without first wading through 100's of sub-sub modules that are irrelevant to me. It seems that I'm not alone in this matter when you read the comments in the issue. It only leads me to question the viability of npm itself when such changes are made without a proper migration from old to new systems. For me, npm2 will always be king.
I get invalid packages installing, even if the installation is a success. Btw, this question is related to the answer - question about versioning
npm install serialport
These are packages which is stuck far in the dependency tree.
npm ERR! invalid: readable-stream#1.0.27-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream
npm ERR! invalid: string_decoder#0.10.25-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream/node_modules/string_decoder
This ends up causing this error in my browser:
Uncaught TypeError: Cannot read property '_ansicursor' of undefined
Is there any way to sort up in this npm problem? Can I avoid these prerelease packages?
The github answere below gave me a lot of insight into npm and I thought I had to dig somewhere else for the issue. But it acctually just seemed like serialport does not work very well, anymore, with browserify. It used to work because i used if for two months, but something changed. When im saying it out loud, it just sounds stupid anyway. So dont browserify serialport.
I recieved an answere on github, issue answere, thought i would share it with the rest who might wonder:
The change in handling prerelease versions in semver#4 is one of the primary motivators for the major version bump to npm#2. All versions of npm 2 are affected by this change, which, put briefly, ensures that all version information to the right of - in version strings is ignored when doing semver range matching. When you upgrade from npm#1 to npm#2, it's normal to see some irregularities show up when you run npm -g ls, and since some packages are distributed as self-contained installs via the use of bundledDependencies, they may come out of the package in a state that is inconsistent with npm#2's rules.
While this won't always work, most of the time the easiest way to fix these issues is simply to uninstall and reinstall the affected package. For packages that ship with bundledDependencies, if you really want to get everything cleaned up, you can cd into the node_modules folder containing the version of the package with the noisy prerelease dependency version and just run npm install problemDependency, and it will use the newest version of that dependency that matches the semver range for that particular package.
Re: your second question, semver range checking is done semantically, not lexically, so 1.0.31 should match with npm#2:
% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31
1.0.26
1.0.31
I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.
All of this is documented, so I'm going to close this issue. I hope this clears things up for you!
Today I upgraded npm and node. I'm at 1.4.9 and 0.10.28, respectively. (OSX 10.9.2.)
Since then, it seems that npm install is writing "bad" package.json files for all of my dependencies.
Specifically, it is putting sevaral fields into the files that do not seem to be present in the source repo's package.json.
Like this example. I have about 40 dev dependencies and they all have this junk (not to pick on gulp, I just happened to grab it for this example):
"readme": "<p align=\"center\">\n <a href=\"http...",
"readmeFilename": "README.md",
"bugs": {
"url": "https://github.com/gulpjs/gulp/issues"
},
"_id": "gulp#3.6.2",
"_shasum": "ea6b33d768db4a22294fa6339afb61842f5e6fb5",
"_from": "gulp#~3.6.2",
"_resolved": "https://registry.npmjs.org/gulp/-/gulp-3.6.2.tgz"
These are on the root of the package.json object. Note, I've abbreviated the readme -- it's an entire html-ized version of the readme, and in many of the files it's not properly escaped and thus makes package.json invalid and unusable.
Obviously this leaves me dead in the water. My questions are "what did I do"? And how do I undo it? Did I wind up with a version of NPM that I shouldn't have? Could there be something else about my project, my node install, or the rest of my environment that might cause this? I do have nave and a version of node in the 0.11 family, but that's not active and hasn't been in recent history -- could npm update -g npm have discovered that I have 0.11 in a different directory and jumped me into territory to which I should not have gone? If so, how to I go backward? I've tried npm installing npm back down into earlier versions but npm still reports the higher version number as if my install didn't happen, and I can't quite figure out what version I'm supposed to have, anyway.
What I've tried so far -- reinstalling node and npm, wiping out my node_modules for the project, and npm cache clean. Nothing seems to have any effect. I'd be happy to answer any questions that I can about my environment that might help me resolve this.
TIA!
I just poked my way somewhat blindly into a solution.
(although I suspect it didn't matter, I upgraded to the master branch code of npm)
I believe that I fixed this by experimenting with setting long = false in my .npmrc file. No more readmes in package.json files! :)
Aside: the package.json content that I see is quite foreign to me in its arrangement, but I guess that may be a function of being on a newer version.
At the very least, the package.json is now valid json and life is better again. I'm not going to accept this, my own answer, just yet because I hope someone might be able to tell me why I needed to do this. This is an override in my .npmrc file as far as I understand it, so it seems bizarre that out of the blue I needed to add this override by hand based on no documentation....
I'll accept an answer that points me to an explanation of what happened or of what might have happened, if there is such an answer! If none are forthcoming, I'll just accept my own answer so that the SO question loop is closed. Thanks!