Aliased dependencies are not linked correctly

[ericcornelissen]

Describe the bug

The npmx interface links to the wrong package when a package specifies a dependency through an alias (e.g., "foo": "npm:bar@1.2.3" in package.json) in the "Dependencies" section of the sidebar. See for example string-width-cjs npm:string-wi... in the preview below:

which currently links to https://npmx.dev/package/string-width-cjs but should link to https://npmx.dev/package/string-width per https://npmx.dev/package-code/@isaacs/cliui/v/8.0.2/package.json#L53.

Additional context

Example:

• For https://npmx.dev/package/@isaacs/cliui/v/8.0.2 the *-cjs dependencies link to the wrong package and should instead link to the aliased package.
• Compare that to https://www.npmjs.com/package/@isaacs/cliui/v/8.0.2?activeTab=dependencies which only links to the correct dependencies¹.

Logs

n/a

Footnotes

1. this appears to be a quite recent change because I definitely remember them linking to the alias-named package not too long ago. See also https://snyk.io/blog/exploring-extensions-of-dependency-confusion-attacks-via-npm-package-aliasing/. ↩

[MatteoGabriele]

Correct me if I'm wrong, but it should also be flagged as 4 versions behind, right?
If string-width v5 shows a 3 major versions behind warning, then string-width-cjs, pointing to string-width v4, should indicate 4 major versions behind.

[ericcornelissen]

You are correct @MatteoGabriele. My guess for why it currently doesn't show that is because it uses the full alias string as the version and probably gets confused. So rather than not flagging it, it just doesn't know the version.

To be more explicit w.r.t. this than the original report, beyond linking to the right package it should also show (and link to, etc.) the version being used rather than the full alias string.

[maxchang3]

Quick note: in Dependencies.vue and related files, dependency values are currently assumed to always be version ranges. In reality, according to npm-package-arg, a dependency can be:

• a Git repo
• a tag / a specific version / a version range
• a local file or directory
• a remote URL
• an alias, like npm:foo@1.2.3

Some of these are rare, but they do exist. For example, on this page, I noticed a dependency that uses file:.

So we might need to introduce a more specific dependency value type and handle each type accordingly。

[MatteoGabriele]

Yes, I took a quick look at how it's currently handled, and it seems like it needs a bigger refactor than I initially thought. We definitely need to manage all types of version declarations and also allow different version resolvers for the same package. Currently, we use an object where each key is a single package with a single resolved version. But as shown in the bug example, string-width will need to resolve both 5.1.2, coming from string-width, and 4.2.0, coming from string-width-cjs.