NPM Connector returns plus "+" in versions

maxim_mazurok

When trying to install @hot-loader/react-dom@16.13.0 from our proget npm registry, I'm getting error:

@hot-loader/react-dom: No matching version found for @hot-loader/react-dom@16.13.0

Installing it from npmjs registry works.

When comparing two responses, I can see that our registry reports version with a plus sign in the middle, and I think that's why npm/cli don't understand that it should use this version:

http://proget.wtg.zone/npm/Registry/@hot-loader/react-dom/
```
"versions": {"16.13.0+4.12.20": ...
```
https://registry.npmjs.org/@hot-loader/react-dom/
```
"versions": ... {"16.13.0": ...
```

I'm using Proget Version 5.2.18 (Build 2)

Does to look like a Proget / NPM Connector bug?
Where should I report it?
Is there anything I can do to fix it?

Thanks!

atripp

Hmm, it's strange. Is this the only package and version that's acting like this? The "+" implies a sort of build-metadata in SemVer, but i'm not sure if npm supports this?

Anyways the npmjs.org version doesn't seem to have the text 4.12.20 anywhere, at all; any idea where that's coming from?

maxim_mazurok

@atripp It is the only package that causes us problems.

This "+" is used to specify related package version, as seen here: https://github.com/hot-loader/react-dom/blob/d33208f02ebef963cdd3e91980b6d2a588588409/auto-publish/utils.js#L234

4.12.12 is coming from the package.json: https://unpkg.com/@hot-loader/react-dom@16.13.0/package.json

I wish we had access to npmjs to see if they are parsing semver and then returning only <version core> from:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

Could we do something similar in ProGet?

atripp

Thanks, that makes sense where it comes from.

Since this is the only package with a problem, I wonder if you could just "republish" it with the build-metadata number missing?

We're a bit hesitant to make change that could impact this. For all we know, this works in older versions of the npm client, or newer versions of the npm client, or the yarn client, etc., and users are relying on this behavior.

maxim_mazurok

@atripp I'm not owner of this package so I personally can't republish, I can only open issue/PR and ask them not to use this build metadata approach. Wich will make no sense, because it's completely legal and handled appropriately by npmjs server and npm client.

What do you mean when you say that it works with older/newer npm client? It doesn't work for me, using latest npm client. I'm getting error that package with that version could not be found (when using ProGet repository) and it obviously works fine when I use default npmjs repository.

So, don't you think that ProGet should act like npmjs? If npm doesn't work with ProGet in this case, what kind of regression could be possible after the fix? I only can see positive outcome, unless some folks already use build metadata in thiers package.json

atripp

What I mean by "republish" it is to republish it to your ProGet feed. This local package will then "mask" the connector package, and ought to behave fine.

In this case, since it's just one package behaving like this, and there's such an easy work around (download package, edit metadata, republish), it's really not worth the investment to even investigate how easy/difficult it would be to fix. If it becomes more widespread, we'll investigate.

This has to be done on NuGet and PowerShell feeds for some old and quirky packages (like ones that have a 1.01.1 and 1.1.1 version). It may be trivial, but it could introduce the exact regression you described (people using build metadata in their package.json), or other (unknown) regressions, and it's just not worth the risk to our users.

maxim_mazurok

@atripp

It's not really easy workaround since I'm not the admin of ProGet in my organization. Also, what will happen to the updates of that package? Will I have to reupload every new version?
It breaks compatibility with original npm, meaning that I can't use the same package.json file with both ProGet registry and npmjs.
If there's a concern about unknown regressions, it can be solved by issuing major release with release notes. Alternatively, you can support both variants by leaving both "x.x.x+x.x.x" and "x.x.x" in the resulting JSON output.

The being said, I've analyzed all 1 240 000+ packages in our ProGet and @hot-loader/react-dom indeed seems to be the only one with "+" in the version field.

Also, I've performed the same check for all packages in npmjs repo, and none of them reported "+" in the version (as expected).

Now, because it's confirmed to be the only package with "+" sign in the version - I think it's reasonable to open an issue in their repo.

atripp

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39