Another situation where external access may be required is when the package author has used npm shrinkwrap to store the resolved URL in a package npm-shrinkwrap.json file and then published this package to the remote registry. When the npm client encounters the resolved field, it tries to contact that URL to download packages, instead of the configured registry in your .npmrc file. If one chooses to bypass the shrinkwrap file, then they might also lose the specific dependency versions that the package depends on.

Another case where external access is attempted by the npm client, is specific to post install scripts executed by certain npm packages themselves, like PhantomJS and node-saas.

Packages like the phantomjs npm are distinct from the actual framework downloadable from phantomjs.org. After it is downloaded through Nexus by the npm command line tool, a post install script is automatically run that attempts to download the complete framework from https://bitbucket.org/ariya/phantomjs/downloads . Your npm client host may be behind a firewall blocking access to this remote site.

These problems are created by the authors of npm shrinkwrap and npm client, or well meaning package authors. Sonatype has filed and commented on several issues with the official npm maintainers about these problems, yet the issues remain despite the support of many community members.

https://github.com/npm/npm/issues/3581#issuecomment-58516251

https://github.com/npm/npm/issues/6444

https://github.com/npm/npm/issues/6445

In summary, the design decisions of the npm repository format authors complicate the adoption of private registries like Nexus. We believe that a repository client should have full control of where packages come from, and that a repository format should instead focus on providing a unique identifier to a component that is source URL independent.

Workaround

Users of npm client are invited to comment on existing issues, or file new issues with npm, if you have an opinion about the design decisions leading to the mentioned problems.

In the case where the package includes a npm-shrinkwrap.json file, you can one time ignore this file by using --no-shrinkwrap argument with your npm install command. Keep in mind this will also ignore explicit dependency versions specified in this file.

The workaround for permanently bypassing embedded package.json URLs ends up being a variation of:

Download the original package and extract it.

Edit the package.json file manually or use a tool like npm shonkwrap to remove the shrinkwrap resolved URLs in the package npm-shrinkwrap.json file

Republish the edited package to a private hosted npm repository in Nexus.