rushstack icon indicating copy to clipboard operation
rushstack copied to clipboard

[rush] Rush publish does not honor npm credentials defined in home directory

Open manrueda opened this issue 5 years ago • 7 comments

Is this a feature or a bug?

  • [ ] Feature
  • [x] Bug

Please describe the actual behavior.

When rush uses the .npmrc-publish to provide custom settings for the publish phase (compared to the install phase), it shadows all configurations from the user's home directory .npmrc.

In this case the problem is that all credentials generated by the npm login --registry=XXXXX will not be used by rush. This makes rush not compatible with tools that follow the npm login pattern. I understand that is possible to provide the token with an environment variable, but this will make us to support two login patters.

Also, this generates an inconsistent behavior between rush install and rush publish. Because rush install does not override the home directory variable so the package manager ends up loading the file from the home directory, while rush publish will never see that file because the home directory is changed.

I am close to implement rush in multiple projects, but this is a deal breaker because changing the credential flow will involve change all our builds structure and re-educate hundreds of developers.

If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.

Yes, just have a set of credentials in your home directory .npmrc and try to use rush publish.

What is the expected behavior?

When overriding the home directory rush could extend the user home directory .npmrc with the content from .npmrc-publish and use the result of it as the publish configuration.

If this is a bug, please provide the tool version, Node.js version, and OS.

  • Tool: rush
  • Tool Version: 5.33.2
  • Node Version: 14.8.0
    • Is this a LTS version? No
    • Have you tested on a LTS version? Yes
  • OS: MacOS

manrueda avatar Aug 26 '20 20:08 manrueda

But you can use rush publish -n <AUTH_TOKEN>

alex-shamshurin avatar Oct 23 '20 16:10 alex-shamshurin

Yes, but currently I do not have the credentials in a ENV variable because I am using the npm login flow to do the authentication.

We have a private registry based on jFrog, so the credentials are handled a little bit differently. It works fine with normal .npmrc file stored credentials.

manrueda avatar Oct 23 '20 19:10 manrueda

In #2536 I proposed:

However, for testing purposes (e.g. against a testing registry like Verdaccio), I agree that it would be useful to access the settings in $HOME/.npmrc. We could support this with a CLI parameter like --use-user-npmrc for rush publish that would skip the logic that sets HOME=common/temp/publish-home.

Would that solve your issue @manrueda ?

octogonz avatar Mar 09 '21 03:03 octogonz

@octogonz Why is this only a Rush issue to use ~/.npmrc for publishing packages whereas other solutions don't think it's a problem and let the responsibility to end-users to take care of their credentials by themselves?

Is this just because:

# common/config/rush/.npmrc-publish
...as publishing often involves different credentials and registries than other operations.

?

If yes, I would be curious to know why would you choose to use different credentials and registries when publishing a package... What makes it so common that it should be the default way to process for everyone, adding complexity and preventing the publishing phase to work with what I supposed to be a typical configuration?

bbenoist avatar Mar 28 '21 07:03 bbenoist

Publishing is normally performed by an automated CI job, which in a corporate environment ensures an audit trail and a record of how the package was built and published. Ordinary users normally would use different credentials for rush install because they should not have write permission to the NPM registry.

octogonz avatar Mar 28 '21 08:03 octogonz

@octogonz I think a CLI parameter like --use-user-npmrc would help. We are currently in the process of migrating a repo to rush and we are using CodeArtifact which generates a .npmrc file within $HOME/.npmrc whenever we login (it has all the required auth stuff). However, it is a bit of a pain to set these values as environment variables - so I currently copy that .npmrc and override the following file common/config/rush/.npmrc-publish.

ddhanak avatar Mar 08 '22 00:03 ddhanak

If someone wants to contribute a PR that adds the suggested CLI option --use-user-npmrc, we would accept it. 👍 As mentioned above it would be useful for testing scenarios such as Verdaccio.

For production, personally I would be uncomfortable with the idea of saving a publishing token on disk in plaintext where any CI job can read it even after the machine is rebooted. If some organizations don't care about protecting their particular NPM registry, that's fine, but it still seems bad to normalize an unsafe practice when there are easy alternatives.

Environment variables do have a downside that child processes can access them, but at least they can't be accessed by other unrelated jobs that may be running on the same machine. (If we could come up with a way to pipe the credentials via STDIN, that would be even better... but popular CI systems don't seem to support that. 🙃)

We have a private registry based on jFrog, so the credentials are handled a little bit differently.

jFrog works just fine with environment variables. You just need to set both values:

common/config/rush/.npmrc-publish

@my-company:registry=https://my-company.jfrog.io/my-registry/api/npm/npm-private/
//my-company.jfrog.io/my-registry/api/npm/npm-private/:_password=${ARTIFACTORY_TOKEN}
//my-company.jfrog.io/my-registry/api/npm/npm-private/:username=${ARTIFACTORY_USER}
//my-company.jfrog.io/my-registry/api/npm/npm-private/:always-auth=true

# All other packages come from the public NPM registry
registry=https://registry.npmjs.org/
always-auth=false

octogonz avatar Jun 10 '22 06:06 octogonz