Dpl: Improve support for GitHub Package Registry

[kripod]

GitHub's setup-node Action provides a special mechanism when the specified npm registry is npm.pkg.github.com. Authentication should be done regularly:

//npm.pkg.github.com/:_authToken=...

But an .npmrc file with a scoped registry is necessary:

registry=https://npm.pkg.github.com/@username

If registry: npm.pkg.github.com is provided in .travis.yml, then dpl should automatically try publishing the package in the correct scope.

[svenfuchs]

thanks for opening this, @kripod.

we finally got beta access to the GitHub package registry for our test account, so i have taken a stab at this. things seem a little odd though.

using this branch https://github.com/travis-ci/dpl/pull/1112 i was able to publish packages here: https://github.com/travis-dpl-test/dpl_test/packages

however ...

• if i use registry: https://npm.pkg.github.com/@travis-dpl-test in the deploy config the package would show up named @travis-dpl-test/dpl_test https://github.com/travis-dpl-test/dpl_test/packages/29813 ... not sure that's the intended result.
• if i use registry: https://npm.pkg.github.com/travis-dpl-test as suggested by the docs https://help.github.com/en/articles/configuring-npm-for-use-with-github-package-registry (registry=https://npm.pkg.github.com/OWNER) and also add "publishConfig": { "registry": "https://npm.pkg.github.com/" } to the package.json (as suggested by the empty "Packges" tab when no packages are present) then it would publish the package with the name dpl_test (as i believe is expected) https://github.com/travis-dpl-test/dpl_test/packages/29808
• if i omit publishConfig in the package.json (as i believe is desirable) and use the same registry https://npm.pkg.github.com/travis-dpl-test ... then the package just won't show up on GitHub's "Packages" tab (despite the npm publish command exiting happily with 0 and reporting no issues).

not sure what to make from this, and if i am missing something obvious.

[kripod]

@svenfuchs Thanks for taking your time to investigate this issue. I had similar experiences as you did, and had to contact GitHub Support to remove my inconsumable package called @kripod/@kripod/standard-hooks _(the duplicate scope is not a typo)._

As a temporary workaround, I’m using the following tweak in .travis.yml: https://github.com/kripod/standard-hooks/blob/2d7a8e3b527504e2ec44528aa60fb79e92137270/.travis.yml#L20-L22

[svenfuchs]

this took me forever to figure out, but dpl v2 now supports publishing to GitHub's npm package registry https://travis-ci.com/travis-ci/dpl/jobs/241185443#L260

this is currently in master but i'll cut a release once CI is all green. i am going to close this issue here. please feel free to reopen it if needed.

[svenfuchs]

@kripod whoops, i haven't seen your comment before i sent mine ... i think it should now be working as expected. please let me know if it doesn't.

[kripod]

@svenfuchs Thanks for the fix! As I see in the test case, the name field in package.json is scoped, but GPR allows publishing packages without specifying scope in package.json through https://npm.pkg.github.com/@owner _(the @ symbol is important)._

May I ask how I can deploy a package with metadata like this to GPR through Travis?

[svenfuchs]

@kripod this is very valuable feedback, thank you.

i now see what you mean. i have made this change https://github.com/travis-ci/dpl/pull/1113 ... which has published https://github.com/travis-dpl-test/dpl_test/packages/29808 from https://travis-ci.com/travis-ci/dpl/builds/130189137

again, this is currently in master only. would you like to give this a shot before i cut a release?

deploy:
  - provider: npm
    edge:
      branch: master

[kripod]

@svenfuchs Awesome, thanks for the quick fix! Unfortunately, I’m not sure about giving it a try anytime soon, but I think you should cut a release anyway if you’ve tested it.

[kripod]

When using https://npm.pkg.github.com/@kripod with a scoped package (e.g. "name": "@kripod/eslint-config"), a package with a false name gets published:

The right one was published with registry: https://npm.pkg.github.com/kripod (without "@").

[svenfuchs]

@kripod thanks for reporting this.

i'm not sure, do you think this is an issue in dpl though? GitHub's docs suggest to use registry=https://npm.pkg.github.com/OWNER, which would map to our --registry option, wouldn't it?

we could consider raising an error, if https://npm.pkg.github.com/@OWNER was given, is that what you are suggesting?

[kripod]

registry=https://npm.pkg.github.com/OWNER should be the "official" solution for sure. But for a better developer experience, I would consider transforming

• /OWNER into /@OWNER for unscoped packages
• /@OWNER into /OWNER for scoped packages

[svenfuchs]

i see. i am not sure if i like automatically fixing the registry for the user though. i think throwing an error that informs the user about the mismatch might be better, what do you think?

[svenfuchs]

turns out the registry url has to include @OWNER in ~/.npmrc in order for the authentication to succeed ... 🤔

[svenfuchs]

i'm confused https://travis-ci.com/kripod/eslint-config/builds/133806484#L401 authenticated just fine without @owner in the registry url, while https://travis-ci.com/travis-ci/dpl/builds/133894046#L240 didn't.