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!
Related
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.
In my nodeJS project suddenly it give error.I do not any upgrade or changes.
When I write NPM start in command line it give that error
ERROR in ./~/css-loader?sourceMap!./~/postcss-loader!./~/sass-loader?
sourceMap&outputStyle=expanded&includePaths[]=c:/TFS/rc1/app/scss&includePaths[]
=c:/TFS/rc1/~/compass-mixins/lib&sourceMap&sourceMapContents=true!./app/scss/_toolkit.scss
Module build failed:
undefined
^
Functions may not be defined within control directives or other mixins.
in c:\TFS\rc1\node_modules\compass-mixins\lib\compass\functions\_lists.scss (line 81, column 3)
# ./app/scss/_toolkit.scss 4:14-337
I reinstall compass-mixins package but it still give same error.Then I looked _lists.scss that file in 81 line there is a code .I deleted that bu it give same error.What should I do?
#if not(function-exists(compact)) {
#function compact($vars...) {
$list: ();
#each $var in $vars {
#if $var {
$list: append($list, $var, comma);
}
}
#return $list;
}
}
I also face the similar problem. And my project is using gulp-sass and compass-mixins. As heart.cooks.mind points out that, gulp-sass is depending on node-sass. And node-sass upgrade one of its dependence libsass to version libsass 3.3.3 Delorean since node-sass 3.5.1.
However, one of libsass 3.3.3 Delorean changes is related to this problem:
'Disallow functions to be defined in control directives or mixins (#mgreter, #1550)'
Obviously, _lists.scss in compass-mixins break this rule. Seems someone raise an issue to compass-mixins and they have idea on fixing it.
Before compass-mixins release the issue fixed version, my temporary workaround is to delete node_modules/node-sass manually and npm install node-sass#3.4.2
I had the same issue,please refer to node sass release 3.5.3 is breaking build and force lock gulp-sass to use the specific node sass library using shrinkwrap and avoid using the buggy version of node sass
I am using Gulp. Version 2.3.0 of gulp-sass breaks it. Go back to Version 2.2.0 and you are all fixed.
Edit:
The real culprit is the node module inside the "gulp-sass" node module known as "node-sass". You can see inside "gulp-sass"'s package.json file that it simply pulling version greater than ^3.5.3.
Even if you go back and reinstall "gulp-sass" to 2.2.0, as I suggested earlier, the package.json file in there will still pull "node-sass" greater than ^3.5.3.
If I use the older version of "node-sass" 3.4.2 that error goes away. I don't know how to fix that in an automated way. In a pinch I was able to fix the problem by copying that folder (that is using 3.4.2) from a different project that works. Now it compiles.
Can someone smarter than me figure out a better way to accomplish this result?
What I (temporarily) did, was to install globally the node-sass v3.4.2, and then replace the gulp-sass version of node-sass (it is located within gulp-sass/node_modules) with this older one.
sudo npm install -g node-sass#3.4.2;
sudo cp -r /usr/lib/node_modules/node-sass/ /usr/lib/node_modules/gulp-sass/node_modules/;
Btw, there is a PR waiting to be merged for this. But if you want to use this today then there's a fork of the merge too.
If you want to use latter then just put compass-mixins: tjenkinson/compass-mixins in your package.json and all will be good.
Update:- There's also an npm package for the latter mentioned in the PR now
Update 2:- This should no longer be a problem with v0.12.8 now
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.
Im trying to figure out how npm versioning works because im getting stuck on two invalid packages. Ref my other question. The module i need, serialport, get these packages invalid, "readable-stream" and "string_decoder". Serialport have downloaded this version:
readable-stream#1.0.27-1
Serialports dependency is
"readable-stream": "~1.0.2"
Readable-streams available versions are:
....
'1.0.26',
'1.0.27-1',
'1.0.31',
....
Which explains why 1.0.27-1 is picked. Because of the tilde and ~1.0.2, meaning that these three numbers have to exist in each version. Ref Jakob Mattsson´s simple article
readable-stream downloads
string_decoder#0.10.25-1
readable-stream again depends on
"string_decoder": "~0.10.x"
And string_decoders available versions are
....
'0.10.24',
'0.10.25-1',
'0.10.25',
'0.10.31',
'0.11.10-1'
....
How come that version is downloaded? Ref the article again, tilde means that it has to has 0.10 in the version number, and x is whatever exists?
Why is not string_decoder#0.10.31 chosen?
I believe my problem in question is related to prereleases that this extra dash is called. Im trying to gather facts to maybe seem if dependencies can get updated.
I recieved an answere on github, issue answer, thought i would share it with the rest who might wonder:
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.
See Node app fails to run because of prerelease for a more detailed answer too why this happens.
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!