Skip to content
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.

optimize and deduplicate tree #9

Closed
isaacs opened this issue Jul 9, 2019 · 2 comments
Closed

optimize and deduplicate tree #9

isaacs opened this issue Jul 9, 2019 · 2 comments

Comments

@isaacs
Copy link
Contributor

isaacs commented Jul 9, 2019

Depends on #13

@isaacs
Copy link
Contributor Author

isaacs commented Dec 6, 2019

Interesting question as to how far we want to go with this.

One simple approach would be:

  • Get the list of nodes grouped by name.
  • For every name with more than 1 instance, get the set of edges in
  • Starting from the deepest in the tree, re-attempt to placeDep, with preferDedupe: true enabled.
  • If it ends up in the same place again, re-attempt with the other nodes in the set.
  • Repeat until every node in the set is unchanged.

I think it might be surprising if npm dedupe fetched new packages from the registry, so it should strictly be placing, not fetching.

A more dramatic and powerful approach would be to implement a variant of pubgrub, falling back to nesting when a conflict can be solved that way. It still won't be able to resolve all peer dep conflicts (eg, root module depends on X and Y which peer depend on incompatible versions of Z), but it would result in much more flattening in any non-pathological use case. Of course, doing that implies:

  • Lots more fetching of packuments, (as opposed to just fetching the manifest which is the best match for a given spec)
  • A dedupe that must reach out to the network.
  • Figuring out how pubgrub would interact with git deps, remote deps, etc. In those cases, I think we'd have to fetch and unpack potentially a lot of stuff. (Imagine a package X where each version depends on a git dep Y with a different hash, or a remote dep Z with a different target url -- we'd have to fetch them all.)

I think as a separate command (or something like npm dedupe --extra-flat or something), it could work, but it would not be network efficient enough for the default install.

@isaacs
Copy link
Contributor Author

isaacs commented May 1, 2020

Better expressed in #66 and #67. If we wanna do something fancier, we can explore that in a future version.

@isaacs isaacs closed this as completed May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant