I'm currently working on a node.js-project and I've been keeping up with the most recent node releases during development. Now that node 6 is out, I wanted to see if I could make that decision as well.
It turns out some of the modules I use are dependent on older versions of graceful-fs which doesn't support node 6. I get warnings when installing and executing my application, but I can't determine where the graceful-fs package is being used (indirectly).
How can I find out?
I am fairly certain this is what you want:
npm ls graceful-fs
See documentation here.
Copying from #Soufiane Ghzal's comment and the npm-ls docs:
To get a "bottoms up" view of why a given package is included in the tree at all, use npm explain.
Related
For instance, say I have "foo: ^1.0.0" listed in my package.json and that project's released versions are [1.0.0, 1.1.0, 1.2.0, 2.0.0]. I want to find out what ^1.0.0 resolves to without installing or looking it up manually. Does a tool for this exist? I would expect it to be something like npm resolve foo#^1.0.0
Yes there is!
If you're using npm use view
npm view foo#^1.0.0
Otherwise you could use yarn with info
yarn info foo#^1.0.0
And in case you want even better statistics check out bundlephobia. It gives size estimations for the given version as well as the others and also an analysis of the exports.
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.
If I write a package I am certain requires Node 4 or higher, I don't want it to be installable with older versions.
I know about the package.json engines field, but that's just advisory (only causes a warning). And enginesStrict has been deprecated.
So what can I do?
One idea is to have a preinstall script that checks the Node version and errors if it's not high enough, preventing installation from continuing. Are there any problems with doing that? And is there a better way?
If you want a good experience, make your CLI entrypoint standard ES5 and CommonJS, detect the node version (process.version), and print a detailed and helpful message then exit non-zero. Keep in mind your module may get installed with some node version then the user futzes with nvm or their PATH or whatever and then runs your code under a different version. Thus I think failing nicely at run time is the most important thing. You can also choose to fail at install time if you like.
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!