[Feature] Support setting npmAlwaysAuth with npm login command

[kherock]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

I believe there's a larger problem around configuration of always-auth behavior that I'll get into, but there's at least a couple solid reasons I think Yarn should implement this command-line switch:

• parity with the npm login/adduser command: https://docs.npmjs.com/cli/v6/commands/npm-adduser
• it simplifies the process of logging into a registry requiring auth down to a single command

In the meantime, my current workaround to get npmAlwaysAuth set is to have a wrapper script that runs

$ yarn config set -H "npmRegistries['$(yarn config get npmRegistryServer)'].npmAlwaysAuth" true

after login.

Describe the solution you'd like

Since logging in is always a required step at some point, it would be acceptable if this additional configuration could automatically happen when I run

$ yarn npm login --always-auth

Describe the drawbacks of your solution

Adding the command line flag fortunately doesn't have any drawbacks I'm aware of. However, the changes I might propose to how npmAlwaysAuth is determined during install would add complexity at the risk of making things more unintuitive.

Describe alternatives you've considered

This addition can be avoided for most use cases with some changes to how registry configuration is resolved in RC files.

Additional context

My use case that this solution would solve is for a project that uses a self-hosted registry (JFrog) for all public packages. However, it's proved difficult to have Yarn understand that authentication is always necessary due to the way it reads registry configuration. Consider the basic example

# ~/.yarnrc.yml
npmRegistries:
  "<my-registry>":
    npmAuthToken: ******

# <my-project>/.yarnrc.yml
npmRegistryServer: "<my-registry>"
npmAlwaysAuth: true

In this case when installing packages from <my-registry>, npmAlwaysAuth is unintuitively false since Yarn prefers the values for registry-specific settings. To elaborate, the npmAlwaysAuth: true in <my-project>/.yarnrc.yml is actually a fallback value that is never used, since <my-registry> exists in npmRegistries, and npmRegistries["npmRegistries"].npmAlwaysAuth has an explicit default value of false.

A potential workaround would be to specify the project's configuration as

# <my-project>/.yarnrc.yml
npmRegistryServer: "<my-registry>"
npmRegistries:
  "<my-registry>":
    npmAlwaysAuth: true

but because Yarn doesn't perform deep-merging for registry configuration, the value for npmAuthToken in the user's home folder is masked away, and now all requests are unauthenticated. Therefore, there is no possible configuration at the project level that can convince Yarn to always authenticate requests for default registry. Configuration must happen in the user's home folder configuration since adding the auth token in the project rc isn't an option.

[arcanis]

because Yarn doesn't perform deep-merging for registry configuration, the value for npmAuthToken in the user's home folder is masked away, and now all requests are unauthenticated. Therefore, there is no possible configuration at the project level that can convince Yarn to always authenticate requests for default registry

That's the actual issue. I'm not very interested to add such a flag on the CLI, because it's registry-specific, not user-specific - and thus it doesn't have anything to do with the login in itself.

What we're lacking are proper merge rules, and that's something that I think we'll be able to tackle in the next major.

[kherock]

I actually view the deep-merging problem as secondary, there's still the confusing behavior in how certain npmAuth* properties cascade that I'd like to address. Some of this undesired behavior was added in #1059, to the point where there's actually this nasty case that I'd almost classify as a latent bug:

npmRegistries:
  "<my-registry>":
    npmAuthToken: ******

npmScopes:
  my-scope:
    npmRegistryServer: "<my-registry>"
    npmAlwaysAuth: true

In this case, Yarn will find the npmAuthToken for packages in @my-scope, but npmAlwaysAuth will be set to false. It's currently worked around by applying AuthType.BEST_EFFORT for scoped packages. Regardless, I think the fact that cascading behavior depends only on where Yarn finds the first defined instance of npmAuthToken and npmAuthIdent is not ideal.

So, regardless of Yarn's behavior of merging configs, it was a real pain to discover that the behavior of npmAlwaysAuth is coupled to the location of npmAuthToken/npmAuthIdent in the configuration. It's what causes this case to misbehave:

npmRegistries:
  "<my-registry>":
    npmAuthToken: ******

npmRegistryServer: "<my-registry>"
npmAlwaysAuth: true

[Psidium]

Oh god I just lost a full working day trying to make this work... Maybe I'm too dumb for not finding this issue sooner...

Are you accepting PRs on this?

[rtrembecky]

there has been a related PR opened - #2116. however, it was closed/postponed and the feature is planned for yarn v3. though no idea when that will get released

[Psidium]

Aren't we on 3.0.1 now? https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md

[rtrembecky]

okay... I had no idea 😄 so it doesn't seem they fixed it as planned here #1406

[smoores-dev]

@arcanis it looks like this didn't end up being included in v3. I assume this means that this npmScopes deep merging is going to have to wait until v4? I wonder if instead we could provide a way to opt in to this behavior explicitly in the yarnrc, so that we don't need to wait for the next major release? I would be happy to work on a PR for this if that were the case; this is a crucial feature for private registries; without it, it's almost impossible to make meaningful use of the yarn npm login --scope command!

[kherock]

I had npmScopes merging basically solved in #2116, and I wouldn't mind resurrecting it if it gets accepted. It had no breaking changes to my knowledge.

[rosskevin]

I appear to have run into this same problem but discovered another reported issue: #4341 (comment)

Ultimately, yarn differs from npm with it's discovery/deep merge (or lack thereof) of configs and it ultimately makes the only working yarn 3 config unusable due to the security hole of having to commit your token to the project's yarnrc.yml.

I'm not sure how this is considered a Feature when authentication to private repos appears to be broken.

[smoores-dev]

In case it helps, the .yarnrc.yml file lets you reference/interpolate environment variables. This is how we use Yarn v3 with private repos at NYT; we have a script that authenticates with our private package registry and sets an auth token as an environment variable, so that our .yarnrc.yml is safe to check in:

npmScopes:
  nyt:
    npmAlwaysAuth: true
    npmAuthIdent: '${ARTIFACTORY_AUTH:-}'

That said, deep merge would make this flow much simpler by totally cutting out the script and making it possible to only rely on yarn npm login!

[tanepiper]

Sort of amazed this hasn't been fixed in nearly a year TBH, it's kind of essential for CI workflows.