I am running command as npm list and I get below mentioned list as my dependencies and I want to know what is the meaning of deduped. Please let me know the meaning of this.
deduped is short for "deduplicated" (duplicates were removed).
The documentation for npm dedupe explains how npm does this:
Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages.
In other words, it looks if multiple packages have the same dependencies (meaning the same packages and version range) and "points" them to the same package.
The same package is referenced, so it doesn't have to be installed twice.
Also, it moves the packages "up the tree" (flattens the tree). This makes total sense as otherwise one package would have to look in the node_modules of some other package (which would be kind of messy) and helps to simplify the dependencies.
You can validate this, as every package in your dependency graph that says deduped, can be found at least one more time in the graph, usually at a higher level.
In the screenshot you posted content-type#1.0.4 is a dependency of body-parser. A bit further down, it's also listed as a direct dependency of express one level higher.
Sadly i can only post it here and not in the comment section, since i don't have 50 rep, but with npm v8.3 you can also use overrides for packages in your tree:
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
Why do i mention it?
-> overrides are also tagged with "deduped" no mater how high they are on tree, so even if package x in branch y is only listened once it still will be marked "deduped"
Related
In abstract, I'm ok with the provided version of dependency-B, which is already installed thanks to dependency-A.
"dependencies": {
"dependency-A": "x.y.z",
}
$> npm ls --depth=1
├─┬ dependency-A#x.y.z
│ ├── dependency-B#x.y.z
So when I require('dependency-B'), I'll expect A's dependency.
I'm using the root function from that library and, in fact, if dependency-A bumps the version, I'd like to align with it and use the same version it uses.
If dependency-B is listed on the dependencies, a brand new package will be installed.
"dependencies": {
"dependency-A": "x.y.z",
"dependency-B": "a.b.c",
}
$> npm ls --depth=1
├─┬ dependency-A#x.y.z
│ ├── dependency-B#x.y.z
│ ├── ...
├─┬ dependency-B#a.b.c
I'm tempted to not list dependency-B on my dependencies. Should I avoid this practise? Isn't ok to rely on the peer version installed by my main dependency?
If this is a brad practise, how can I tell npm to give me the very same version it's installed by another package?
"dependencies": {
"dependency-A": "x.y.z",
"dependency-B": "~try the one that is installing dependency-A~",
}
tl;dr: You should always have all dependencies that you're using in your own dependencies object, as conformant implementations of package managers are not required to give you access to your dependencies' dependencies.
This is an interesting question, and I can think of two scenarios in which you might encounter this:
Both your package and dependency-A use dependency-B independently, for your own set of reasons, and you simply don't care which version to use.
You need to use dependency-B in order to interact with dependency-A, by creating objects of B or receiving objects of B created by A.
Scenario 1: Independent usage
If you and your dependency need the same package but don't need to share anything about it, Node gives you the amazing ability of using different versions of the same package in different places by specifying different versions in the package.json of your package and your library's. This is one of the strengths of the Node module system.
Your situation, however, is that you don't care about the actual version of the package (which makes me think this is not your scenario). In particular, you wonder if it's just better to not define anything in your own package.version and just let Node find your dependecy's dependency.
This last situation is only possible because you're using npm, and npm does one particular thing: it flattens the module tree in an effort to deduplicate packages, that is, so that multiple dependency specifications that can be satisfied by the same version are, in the end, using the exact same version. This reduces both the size and depth of the module tree, but creates the unintended consequence that you now have access to packages you havent specified as dependencies, just because they were installed in you node_modules directory for the purpose of deduplication.
This is not the only possible strategy though, and pnpm, another package manager, instead useds symlinks to achieve the same goals. I won't enter into much detail, but pnpm installs all dependencies in a different, system-wide (or user-specific) directory, and then symlinks from your node_modules (and from the dependencies' own node_modules) to the appropriate location in that folder. This achieves not only project-wise deduplication, but system-wide deduplication, as all of your projects using a specific package version will use the same installation. The consequence of this system, though, is that you "lose" the ability to use your dependencies' dependencies in your own package, because they're no longer physically in node_modules.
Apart from all that, is the idea that you don't care about the version they use. That's almost never the case, as the whole point of semantic versioning is to avoid or contain breakage due to dependency version upgrades. You don't care about the version you use now, but if that package gets upgraded in your dependency to a different major version, your package can break unexpectedly.
In conclusion, not defining a dependency that you are going to use anyway is a bad practice, both because it prevents other developers from using your package in a different package manager, and because it opens you to unexpected breakage that you won't be able to properly manage.
Scenario 2: Dependent usage
The more likely scenario given your description of the problem is that at some point in your usage of dependency-A, either it asks for something or returns something from dependency-B. In this situation it is desirable that both use the same, or at least compatible versions, so that all assumptions about the shape of the objects that are being exchanged hold.
The correct way of specifying this situation is to explicitly declare dependency-B as a peer dependency of dependency-A. If that's not the case, they're not being correct and you should most definitely bring that up in an issue if possible. As a workaround, you might just declare the same version as them and be wary o possible breakages due to version upgrades on their part. Not defining anything in your own package.json can have the same problems as in Scenario 1.
However, another possibility is that you don't even need to require that dependency. It might be the case that they expect you to pass data, functions, objects or anything that will be further passed to dependency-b, but in a way that shields you from ever having to interact with dependency-B directly. In this situation, they're essentially incorporating part of B's API into their own, and therefore any breaking change from dependency-B should also incur in a breaking change of dependency-A. This shields you from unexpected breakages, avoids you having to define anything in your package.json and means you're safe.
I'm a bit confused about how a dependency on a package affects including it in Stackage LTS; specifically, if
package A requires package B, and
package A works when package B is installed as an extra-dep on top of LTS-X.Y, but
package B itself is not in LTS-X.Y,
does package A have to be excluded from LTS-X.Y, particularly if
the only reason B is excluded is because of a test suite dependency, not a dependency in the library itself?
I'll copy/paste my answer on github
does package A have to be excluded?
No, it doesn't have to be excluded. Here's why:
even if the only reason B is excluded is because of a test suite dependency
In this case, we can add B to the build plan and mark it under the skipped-tests section in order to avoid pulling in its test suite dependencies. This is true of both LTS and nightly snapshots.
(However, a preferable course of action would be to remedy B's dependency issue so that the test suite can be run.)
To further clarify, in response to #bergey's answer:
packages are only included if the package's maintainer agrees to keep it up to date with respect to its dependencies
This is only true of packages explicitly included. Some packages are transitive dependencies, which are included implicitly, and are not necessarily held to such strict standards. (However, in the future we may eliminate the concept of implicit inclusion and instead include all packages explicitly.)
Exceptions can also be made so that a package may be included, even though its test suite or its benchmarks have incompatible dependency constraints with the snapsnot.
Of course the preferred way to go is to not need to make such exceptions, and we encourage all maintainers to keep all of their build targets up to date.
Finally, allow me to note that this question would probably be more well suited for the stackage mailing list, which is admittedly not well publicied or utilized.
Yes, for every package in a given Stackage snapshot, all of its transitive dependencies are also in the snapshot. Also, packages are only included if the package's maintainer agrees to keep it up to date with respect to its dependencies. There are more details about this in the README on github. An excerpt:
All packages are buildable and testable from Hackage. We recommend the Stack Travis script, which ensures a package is not accidentally incomplete.
All packages are compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot (more information on lenient lower bounds).
Common practice for version numbers of npm dependencies in package.json has been to enter exact version numbers (like 1.2.4) instead of inexact version numbers (like ^1.2.4 which allows installing bug fix releases like 1.2.5) to make sure a future installation will not break due to changes in dependencies (see for example this article).
Using exact version numbers has a drawback in that you can't automatically update bug fix versions of dependencies. This is an issue when it's nested dependencies having security fixes or bug fixes. For example, at this moment the package karma-browserstack-launcher uses browserstack, which is using an outdated version of https-proxy-agent containing a security vulnerability. This becomes very visible right now thanks to npm audit which looks for security issues in dependencies.
Since some time we have package-lock.json, which is used to lock down the version numbers of all dependencies. This may change the way we deal exact or inexact version numbers in package.json.
My question is: given package.json and package-lock.json, what is the best strategy nowadays to deal with version numbers of dependencies? Use exact versions or not? How can I deal with security issues in nested dependencies if they don't get upgraded?
My feeling is that
packages that are libraries and meant to be used to others should have inexact version numbers and should specify the minimum they require in order to work; and
top-level projects that aren't going to be included elsewhere should specify the full version numbers of their requirements, so they can have the most control over when things are updated.
Hello I'm new to Node and in particular the dependency management system. When installing a module I find that my codebase is being covered by lots of dependencies when the actual code I've written is not that lengthy. I've also noticed that sometimes when I do an npm install instead of packaging all of the dependencies under one folder representing the module I'm downloading sometimes the modules dependencies endup sitting in parallel polluting the main folder. For example, I created a module that had maybe 3 sub modules that all are used by the main module and fit well together.
index.js
node_modules
my_authentication_module
my_authorization_module
my_persistance_module
Then when I installed an AWS dependency the number of modules jumped considerable so my code base looks like
index.js
node_modules
my_authentication_module
my_authorization_module
my_persistance_module
aws_module_1
aws_module_2
.
.
.
.
.
aws_module_20
Problem
This is cluttering my code and making it look like theres a lot more going on than there is. Is there a more efficient way of managing a node project?
Secondary Question
How come running "npm install some-module --save" does not confine all of the modules dependencies to a single folder? Or is there a way of doing this so that if some package needs 50 packages I don't end up with 50 packages sitting in parallel with the package that needs them.
For example. Instead of:
node_modules
my_authentication_module
my_authorization_module
my_persistance_module
aws_module_1
aws_module_2
.
.
.
.
.
aws_module_20
It would be nice to get
node_modules
my_authentication_module
my_authorization_module
my_persistance_module
aws
node_modules
aws_module_1
aws_module_2
.
.
.
.
.
aws_module_20
So at least navigating to the top level you can easily see theres only really 3 modules of interest with a bunch of AWS dependencies crammed neatly into one folder. Is anything like this possible?
You seem to be misinterpreting the purpose of node_modules. It is exclusively the province of npm (or yarn etc.). It will never include your own code (except perhaps other separate packages of yours, which are brought in as dependencies). It is (usually) not version-controlled; that is, it is .gitignored'd. At any point, it should be able to erased entirely and repopulated with a simple npm install. Of course, as with anything, there are more nuances and divergent opinions here that are discussed in detail across the web.
There are many ways to manage and structure your own code and artifacts. In many cases, it will go under a src or possibly lib directory at the top of the project, parallel to node_modules. Within src, some people prefer to group code by function (eg, controllers, routers, services), while others prefer to group by area of concern--that's a matter for the project owner to decide.
In any case, since node_modules is fundamentally not your direct concern, it is of no real consequence whether npm organizes the dependencies in hierarchical fashion, as was the case with npm#2, or in flat fashion, as with npm#3. Yes, it can be a bit disconcerting to see a node_modules with 100 entries or 500, but that's really a matter for npm to worry about, and there are good reasons for the change made with npm#3.
I am trying to install some node modules for my application.
Now after entering this command: npm install laravel-elixir it creates a folder node_modulesand installes over a hundred modules!! this cannot be right.
How would I solve this problem?
How would I solve this problem?
Write your own code from scratch.
Really, there's very little that can be done. Large dependency trees are very common in Node.js. A lot of modules are built on the backs of other modules. The module in question is an especially large piece of software, trying to do what seems like a lot of different things, and relying on many other modules to do so.
You can try
$ npm install laravel-elixir --no-optional
to see if you can trim some optional dependencies from the tree. Another methood is to add optional=false to your .npmrc.
In my brief, and unscientific testing this seems to drop about six dependencies from the tree. Not much.
You should also make sure you've updated to npm 3.0 (3.8.6 being the latest), as it does a better job of flattening dependencies.
Sometimes there are needless dependencies in the middle of a tree, and in that event there is not much you can do other than reach out to the maintainers, and see if these dependencies can be removed, but then all the downstream packages will need to update.
This is generally called depedency hell, and it is an unfortunate symptom of certain modules that rely on too many submodules.
In reality though, if this module does what you need it to do, and there are no ill effects of having many dependencies installed, does it really matter? Other than the install time, when using the module, can you tell that it is pulling in a lot of other modules?