Would be great to have this option to use npm audit. ProGet is used in a corporate environment, where security is a pretty high priority, so not having npm audit working is kind of a deal-breaker, IMO.

This is what fixed the issue:

After pulling the package last week, I deleted it and re-pulled just now

Is this a cached package from a connector or did you upload this package directly?

It is a cached package from a connector, we didn't upload this package directly.

Has this version always been a problem or is this new?

This has worked before, as it was added to the lock file with the correct resolved URL and correct SHA, so I believe it's a new issue.

Our guys have fixed the issue somehow, I'll let you know the details of the fix once I have them. Thanks!

ProGet Version 5.2.18 (Build 2)

User getting error:

npm WARN tarball tarball data for node-ipc@http://proget.wtg.zone/npm/Registry/node-ipc/-/node-ipc-9.1.3.tgz (sha512-8RS4RZyS/KMKKYG8mrje+cLxwATe9dBCuOiqKFSWND4oOuKytfuKCiR9yinvhoXF/nGdX/WnbywaUee+9U87zA==) seems to be corrupted. Trying again.
npm WARN tarball tarball data for node-ipc@http://proget.wtg.zone/npm/Registry/node-ipc/-/node-ipc-9.1.3.tgz (sha512-8RS4RZyS/KMKKYG8mrje+cLxwATe9dBCuOiqKFSWND4oOuKytfuKCiR9yinvhoXF/nGdX/WnbywaUee+9U87zA==) seems to be corrupted. Trying again.
npm ERR! code EINTEGRITY
npm ERR! sha512-8RS4RZyS/KMKKYG8mrje+cLxwATe9dBCuOiqKFSWND4oOuKytfuKCiR9yinvhoXF/nGdX/WnbywaUee+9U87zA== integrity checksum failed when using sha512: wanted sha512-8RS4RZyS/KMKKYG8mrje+cLxwATe9dBCuOiqKFSWND4oOuKytfuKCiR9yinvhoXF/nGdX/WnbywaUee+9U87zA== but got sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==. (0 bytes)

http://proget.wtg.zone/feeds/Registry/node-ipc/9.1.2 - exists
http://proget.wtg.zone/feeds/Registry/node-ipc/9.1.3 - doesn't exist, returns 404
http://proget.wtg.zone/feeds/Registry/node-ipc/9.1.4 - exists

The SHA that we're getting is for an empty file. I tried to download http://proget.wtg.zone/npm/Registry/node-ipc/-/node-ipc-9.1.3.tgz manually and it's empty: 0 bytes. So the local cache is not the issue.

Workarounds:

• update the package to any other version
• use npmjs.com registry (https://registry.npmjs.org/node-ipc/-/node-ipc-9.1.3.tgz works and matches sha)

Also, guys in charge of our ProGet install confirmed that this is an internal ProGet error:

System.InvalidOperationException: unsupported archive type at Inedo.ProGet.WebApplication.SimpleHandlers.PackageFiles.InedoArchiveFactory.Open(Stream stream)

@atripp

1. 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?
2. It breaks compatibility with original npm, meaning that I can't use the same package.json file with both ProGet registry and npmjs.
3. 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 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 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?

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!