We have deployed Nexus 3.15.2-01 OSS using the docker container. It is using Azure BLOB Storage.
There is a group NPM repository called npm-all with 2 repositories, a hosted and a proxy.
Users have the following privilege: nx-repository-npm-view--
I’m not sure when it started (with 3.15.2 or before), if a version of package is not already mirrored then requesting it fails.
If the user has the nx-all role then the new version is downloaded and available for all users with their existing privileges.
Is there a specific privilege that should be attributed to users so that a request to a new version of an proxied npm package is automatically downloaded?
After creating a new proxy repository and replacing the old one in the group, the packages seem to be downloaded again automatically.
We’ll see when we upgrade one of our dependency for a newer version not yet released if it still works.
I’m hitting the same problem. The only solution for now is hitting the invalidate cache button in the UI.
I’m also not sure if this is 3.15.2 related, but my colleges first saw this problem around 14 days ago.
I’m waiting for them to report again when the problem occur to check it out. Is there anything special I could try so it would help confirm the problem?
There was an issue with the npm registry’s CDN provider last week that caused npm packages and metadata retrieved from the npm registry to be corrupted. It seems it may be resolved now.
Facing the same issue here. I am able to download the packages directly from NPM, but when using the Sonatype proxy, the latest versions are not found.
We found a recent regression with NPM and metadata max age. May be the cause of some problems here: https://issues.sonatype.org/browse/NEXUS-19384
Please follow that JIRA for updates if that seems plausable; it’s high on our priority list.
We generally deploy our docker images right after we deploy our download binaries to the site. They have the same fixes. Stay tuned for a release announcement on this site=) Thanks for your patience.
@vakkomkamal The issue I linked was fixed long ago. I’m not saying there isn’t another issue but the gui and CLI should get the same stuff if caches are clear, so I suspect what you’re seeing is not a NXRM issue and definitely isn’t the ticket I linked.
If you believe otherwise, you’re welcome to file in the bug tracker. If you do, I’d recommend you include a support zip and what npm client version you’re using.
I’m also assuming you’re on a newer version of NXRM.
-Joe
I see no other reports of this image in JIRA, so just the 3 here in this forum since the bug reported was fixed. It did prompt me to check and see if something had missed triage. If you create one, feel free to reference this thread.
I have a similar issue in the version OSS 3.37.3-02. To exclude all other issues I deployed a new instance (in the docker container), configured it with npm-proxy, npm-hosted and npm-group which is combining all of them. Some packages can be installed and downloaded normally, but some of them (nanoid@3.1.31 for instance) can’t be installed with ETIMEDOUT error. Direct access to the NPM registry works as expected.
I have tried to reduce the timeouts in the metadata and components age, invalidate the cache and rebuild the index, nothing helps.
Diagnosing what is actually happening is not easily done unless we have both full client side and repository side logs at time of reproduce. If you have a package.json that helps reproduce the issue reliably, please open a new issue in the NEXUS project at https://issues.sonatype.org with complete reproduce information and logs.