🐛 Bug: Parse mode doesn't like org-scoped registries

[james-nash]

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Expected

Running npx -y --registry https://registry.npmjs.org azdo-npm-auth on a project whose .npmrc uses an org-scoped registry config, like:

@myorg:registry=https://pkgs.internal-repo.myorg.com/foo/bar/baz

...should just work™️ as per the README.

Actual

The command fails with the error: Error parsing project .npmrc.

Additional Info

I presume this is to do with the org scoping, because when I removed the @orgname: prefix in my .npmrc, it worked fine.

[johnnyreilly]

You might be onto something here! I think I need to better understand org scoping. This is instructive:

; bad config
_authToken=MYTOKEN

; good config
@myorg:registry=https://somewhere-else.com/myorg
@another:registry=https://somewhere-else.com/another
//registry.npmjs.org/:_authToken=MYTOKEN
; would apply to both @myorg and @another
; //somewhere-else.com/:_authToken=MYTOKEN
; would apply only to @myorg
//somewhere-else.com/myorg/:_authToken=MYTOKEN1
; would apply only to @another
//somewhere-else.com/another/:_authToken=MYTOKEN2

Consider the kind of thing azdo-npm-auth makes now:

; begin auth token
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/registry/:username=org-name
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/registry/:_password=BASE64ENCODEDPAT
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/registry/:email=npm requires email to be set but doesn't use the value
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/:username=org-name
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/:_password=BASE64ENCODEDPAT
//pkgs.dev.azure.com/org-name/_packaging/org-feed-name/npm/:email=npm requires email to be set but doesn't use the value
; end auth token

and consider your example of:

@myorg:registry=https://pkgs.internal-repo.myorg.com/foo/bar/baz

what would we expect? Perhaps:

; begin auth token
@myorg:registry=https://pkgs.internal-repo.myorg.com/foo/bar/baz
//pkgs.internal-repo.myorg.com/foo/bar/baz/:username=org-name
//pkgs.internal-repo.myorg.com/foo/bar/baz/:_password=BASE64ENCODEDPAT
//pkgs.internal-repo.myorg.com/foo/bar/baz/:email=npm requires email to be set but doesn't use the value
//pkgs.internal-repo.myorg.com/foo/bar/:username=org-name
//pkgs.internal-repo.myorg.com/foo/bar/:_password=BASE64ENCODEDPAT
//pkgs.internal-repo.myorg.com/foo/bar/:email=npm requires email to be set but doesn't use the value
; end auth token

Would this work for your use case?

[james-nash]

I think, you shouldn't duplicate the @myorg:registry=URL bit in the user's ~/.npmrc. IMHO, that's a per-project choice between the unscoped "I want npm to load all packages from this custom registry" versus "I want only packages whose names begin with @myorg/... to be loaded from this custom registry, and anything else comes from npmjs.com as usual".

All we need in the user's ~/.npmrc is the auth details for each registry.

So, I would suggest the behaviour should be:

• Look for registry=[URL] and @[org-name]:registery=[URL] lines in the project .npmrc.
• For each URL that you find, add a corresponding...

  ; begin auth token
  //[URL]:username=...
  ...
  ; end auth token

  ...block to the user's .npmrc.

Considering that folks might be using azdo-npm-auth with multiple projects on their machine, it would be nice if it was smart enough to not overwrite the user's ~/.npmrc , but intelligently find and update existing entries with a matching URL, and only add new ones when needed.

[johnnyreilly]

So it's just the parsing that you think should be amended?

So if it could cope with

@myorg:registry=https://pkgs.internal-repo.myorg.com/foo/bar/baz

as well as

registry=https://pkgs.internal-repo.myorg.com/foo/bar/baz

it'd be fine?

Considering that folks might be using azdo-npm-auth with multiple projects on their machine, it would be nice if it was smart enough to not overwrite the user's ~/.npmrc , but intelligently find and update existing entries with a matching URL, and only add new ones when needed.

I take you're point on this, but I'd like to tackle this separately

[james-nash]

Yup, I think that's correct.

Agreed that the multi registry auth stuff feels more like an enhancement. I'm happy to write up a separate issue for that if it helps.

[github-actions]

🎉 This is included in version v1.2.0 🎉

The release is available on:

• GitHub releases
• npm package (@latest dist-tag)

Cheers! 📦🚀