Unable to browse published npm packages on Nexus - npm

NPM publishes to Nexus under the dash "-" folder. Packages cannot be viewed using Browse Storage.
How to avoid the dash "-" folder?
Is there way to publish npm packages with the folder structure like NuGet?
Is it possible to have a structure like this?
PRIVATE_NPM/
|
|--package-1.0.0/
| |
| |--package-1.0.0.tgz
|
|--package-1.0.1/
|
|--package-1.0.1.tgz

The repository structure in Nexus is standard, and the "-" is part of that standard, it's used to retrieve metadata.
There is a declined feature request (Nexus 2.10) for an NPM package browsing UI.

Related

EINTEGRITY error when using Nexus proxy npm repo

So far we could build our node projects with default registry in .npmrc (registry = https://registry.npmjs.org/). We want to start publishing our internal libraries in local npm repository - we use Nexus 3. I created proxy repo directing to https://registry.npmjs.org/ (https://nexus.local/repository/npm-registry/). When we change registry in .npmrc for that proxy repo, building the same projects ends with errors like:
npm WARN tarball tarball data for wildcard#https://nexus.local/repository/npm-registry/wildcard/-/wildcard-2.0.0.tgz (sha512-JcKqAHLPxcdb9KM49dufGXn2x3ssnfjbcaQdLlfZsL9rH9wgDQjUtDxbo8NE0F6SFvydeu1VhZe7hZuHsB2/pw==) seems to be corrupted. Trying again.
npm WARN tarball tarball data for minimist#https://nexus.local/repository/npm-registry/minimist/-/minimist-1.2.6.tgz (sha512-Jsjnk4bw3YJqYzbdyBiNsPWHPfO++UGG749Cxs6peCu5Xg4nrena6OVxOYxrQTqww0Jmwt+Ref8rggumkTLz9Q==) seems to be corrupted. Trying again.
npm ERR! code EINTEGRITY
npm ERR! sha512-JcKqAHLPxcdb9KM49dufGXn2x3ssnfjbcaQdLlfZsL9rH9wgDQjUtDxbo8NE0F6SFvydeu1VhZe7hZuHsB2/pw== integrity checksum failed when using sha512: wanted sha512-JcKqAHLPxcdb9KM49dufGXn2x3ssnfjbcaQdLlfZsL9rH9wgDQjUtDxbo8NE0F6SFvydeu1VhZe7hZuHsB2/pw== but got sha512-l5E0KJ9dH5bNZ9CxPNtF5KiMPlhF4eQZv7S2+Ko1HbeKTgRr9sMd8oe88VGS14dLESGihS27fqbDXq9d919xcw==. (33280 bytes)
Checking details about wildcard#2.0.0 package using both .npmrc configurations return the same result (especially the same sha512 value):
[jenkins#jenkins-agent-02 tmp.build]$ ~/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/NodeJS_18.6.0/bin/node ~/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/NodeJS_18.6.0/bin/npm view wildcard#2.0.0
wildcard#2.0.0 | MIT | deps: none | versions: 10
Wildcard matching tools
https://github.com/DamonOehlman/wildcard#readme
keywords: string, wildcard
dist
.tarball: https://registry.npmjs.org/wildcard/-/wildcard-2.0.0.tgz
.shasum: a77d20e5200c6faaac979e4b3aadc7b3dd7f8fec
.integrity: sha512-JcKqAHLPxcdb9KM49dufGXn2x3ssnfjbcaQdLlfZsL9rH9wgDQjUtDxbo8NE0F6SFvydeu1VhZe7hZuHsB2/pw==
.unpackedSize: 21.7 kB
maintainers:
- damonoehlman <damon.oehlman#sidelab.com>
dist-tags:
latest: 2.0.0
published over a year ago by damonoehlman <damon.oehlman#gmail.com>
I checked sha512 after downloading that package through our Nexus (https://nexus.local/repository/npm-registry/wildcard/-/wildcard-2.0.0.tgz) using command shasum -b -a 512 wildcard-2.0.0.tgz | awk '{ print $1 }' | xxd -r -p | base64 and it returns l5E0KJ9dH5bNZ9CxPNtF5KiMPlhF4eQZv7S2+Ko1HbeKTgRr9sMd8oe88VGS14dLESGihS27fqbDXq9d919xcw==. I have no idea why that sha512 was changed during downloading package through local Nexus.
I tried to invalidate cache in Nexus proxy repo configuration. Also checked some options in configuration view.
Problem was caused by Apache proxy configuration. Option AddEncoding must not include .tgz value.

How to list all registries npm would use?

I have a package in a private registry. I know it is there as I can pull it into some projects, but I can't pull it into one. I have the correct .npmrc one directory up but am still getting a 404 error.
Is there a way to check all registries that npm would use on install?
You can show the registry of a specific package with the npm view command.
> npm view angular
angular#1.7.5 | MIT | deps: none | versions: 136
HTML enhanced for web apps
http://angularjs.org
keywords: angular, framework, browser, client-side
dist
.tarball: https://registry.npmjs.org/angular/-/angular-1.7.5.tgz
.shasum: d1c1c01c6f5dc835638f3f9aa51012857bdac49e
.integrity: sha512-760183yxtGzni740IBTieNuWLtPNAoMqvmC0Z62UoU0I3nqk+VJuO3JbQAXOyvo3Oy/ZsdNQwrSTh/B0OQZjNw==
.unpackedSize: 2.1 MB
maintainers:
- angular <devops+npm#angular.io>
- angularcore <angular-core+npm#google.com>
- petebd <pete#bacondarwin.com>
dist-tags:
latest: 1.7.5 old: 1.2.32 previous_1_4: 1.4.14 previous_1_5: 1.5.11
published 4 weeks ago by petebd <pete#bacondarwin.com>
When you use npm config get registry you will see the default registry.
> npm config get registry
https://registry.npmjs.org/
With npm config list you can see custom configurations. When you have registered a registry for different scopes you will see them here
#polymer:registry=<url register A>

Nexus OSS 3 - npm install requires npm login

We've started using Nexus OSS 3 as a standalone NPM server and so far it's working great but there's one thing that makes little sense to me, and that is the requirement to do the npm login before being able to npm install self published packages.
We're following the proposed repository structure:
npm_proxy - to use as proxy toward npm public repo
npm_private_internal - to use to upload self created internal packages
npm_private_external - to use to upload 3rd party packages
npm_group - to wrap all of them together so they're reachable with one URL
Now I understand that npm login should be required when publishing a new package, but why is it required when doing npm install of one of the self published packages, and can it be avoided ?
It's not required if you allow anonymous read privileges to your npm repositories. But I guess you've not given these privileges to the anonymous user?
If so, the alternative would be to base64 encode the needed credentials in your .npmrc file as described here:
https://books.sonatype.com/nexus-book/reference/npm-deploying-packages.html
But using npm login would be preferable.

Why npm packages stored via Artifactory have '-' (dash) in their path?

After setting up a remote repository for NPM and having successfully retrieved the dependencies via Artifactory, I saw that all NPM packages are stored with an intermediate dash '-' in their path, such as :
http://host:8081/artifactory/npm-remote-cache/abbrev/-/abbrev-1.0.7.tgz
It's also the same for the published version to a local npm repository.
Both repositories are using the npm-default layout.
No big deal there, but does anyone know why is this dash here in the middle ?
Thanks in advance !
This is done in order to follow the layout used by the public NPM registry.
For example, in the case of the package you mentioned the public URL would be - http://registry.npmjs.org/abbrev/-/abbrev-1.0.7.tgz

How to unpublish npm packages in nexus oss

I've setup an Nexus (2.10.0) NPM repository and administrate an user with full access to this repo.
By setting the "_auth" and "always-auth" param in my local .npmrc the publishing and reading of npm artifacts are working well. But if i try to unpublish or deprecate an npm artifact i get still an error "...This request requires auth credentials. Run npm login and repeat the request...".
What is the preferred way to remove artifacts from an nexus npm repository?
thx,
David
Unpublish is currently not supported. Details see https://issues.sonatype.org/browse/NEXUS-6892
Also keep in mind that is not considered good practice to use unpublish as you can see from the npm documentation itself linked in the issue.
Unfortunately, Nexus 2.11 doesn't support npm unpublish or npm deprecate.
If the goal is to make your previously published versions of npm-packages inaccessible:
You can delete the packages from Nexus by manually removing the tarballs from .../nexus/storage/<your_npm_repo>/<your_package>/-/ on your Nexus server and creating a scheduled task to 'rebuild hosted npm metadata':
The npm metadata for a hosted repository
can be rebuilt based on the components found in the storage of a
hosted repository. The task can serve as a recovery tool in cases
where the npm metadata database got corrupted or the component storage
was created manually or via some external process like e.g. an rsync
copying.
This also works great for injecting old versions of packages into your npm-repo. (To get these tarballs, use npm pack.)