github tarball url in package-lock breaks builds that use private registries and always-auth = true

For users who:

• Are using a private npm registry like Artifactory
• and running npm install in a docker build,
• but do not want to (or cannot, for regulatory/security purposes) pollute their docker image with a github token,

… the following change has broken the installation of winston-daily-rotate-file:

https://github.com/winstonjs/winston-daily-rotate-file/commit/1254aa01e4bb4bd944a5946f864dc64c456e03fb

In the conditions above, this change produces the following error:

44 verbose stack Error: Unable to authenticate, need: Basic realm="GitHub"
44 verbose stack     at /usr/local/lib/node_modules/npm/node_modules/npm-registry-fetch/check-response.js:107:17
44 verbose stack     at processTicksAndRejections (internal/process/task_queues.js:97:5)
45 verbose statusCode 401
46 verbose pkgid winston-transport@https://github.com/winstonjs/winston-transport/archive/868d6577956f82ee0b021b119a4de938c61645f7.tar.gz

The reason for this error seems to be that when always-auth = true is in play npm attempts to authenticate with github instead of just fetching the tarball as a public non-authed user.

There doesn’t appear to be an easy fix for those of us who have the above requirements except to pin to an earlier version of the package and hope that the github URL eventually disappears from the package-lock.

[mattberther]

Would the fix proposed in #315 actually solve this problem and the problem from #314 while making sure the ts typings work as expected (#297)?

[mattberther]

Thanks for the feedback. I’ve merged #315 and pushed as winston-daily-rotate-file@4.5.5. This should hopefully address all of the problems in the best way possible. Meanwhile, I’ll track winston-transport and will remove the workaround once a new version is pushed.