One of my biggest problems with JavaScript and Node.js dependency trees is that it's... never been super easy to understand what you've got and wha...
For further actions, you may consider blocking this person and/or reporting abuse
Out of curiosity, if you are running
nmp installwithin your CI/CD pipeline, would inconsistencies betweenpackage.lockandpackage.jsonnot be picked up there? And if so, what’s the benefit of this?This is assuming that a
package-lock.jsonfile exists. Some projects (like most of mine) opt out of this because it adds maintainer burden for no tangible benefit, at least in the case of modules. It's definitely recommended for applications, but sincepackage-lock.jsondoesn't get published to the registry there's really very little point to keeping it around.That said, as far as I know (and I could totally be wrong!) you can still have unmet dependencies that wouldn't be caught between
package-lock.jsonandpackage.json.shrinkwrap.jsongets published :vIndeed it does, but it’s an antiquated approach that I try to keep out of my open-source packages.
IMO the cost of maintaining an
npm-shrinkwrap.jsonis higher than writing high-quality code that will be resilient enough to handle dynamic dependency resolution.If I am feeling especially picky about a certain module or set of modules, I’ll generally pin the versions in my projects’
package.jsonIt doesn't matter what kind of code you write if your dependencies introduce bugs or change published API with a patch version :D
You could not include those dependencies 😂
Be serious 😂
George, if you have inconsistencies between the package manifest and the package lock, an
npm installor ayarn installwill produce different install results. Meaning to say, the lockfile will not be used as the source of truth.Exactly for that you should actually use
npm ciin order to force the lockfile.I wrote about it in short here: dev.to/lirantal/so-you-think-youre...
Is there a way to
npm ls ...for below a version number? For example, if I donpm -ls lodashI get a huge tree, mostly all on the latest version. I just want to see where the non-latest versions of the package are.As far as I know, not currently. If you were absolutely dead-set on doing this, you could output the command text to a file and then grep that file (or use JSON output and then parse the JSON with
jq).I mostly live behind the corporate firewall and only pop out now and then. I have had similar issues when I want to discover what or how a module is used in an app. In the end I wrote mod-dep-mod. Which my friends and I find useful as you can run it locally and point it to github to search the dependency tree when you cannot actually install locally.
I appreciate the article, I often these pointers really helpful as we get comfortable with what we think the commands do and stop investigating, and I had not heard of dev.to either till this morning.
The gist below that line shows the same long list of dependencies. I guess you wanted to show a different gist?
I had to trim the first gist, since it was literally longer than the content of the post – added a link to the full gist at the bottom of the updated first gist. I'll update the post to include that in the content too!
Edit: Updated!
Great article. When I run
npm lsfrom the root project directory, I'm not getting the list of sub dependencies rather only the dependencies inpackage.json. Do you know why that's the case ?