feat: double publish the NPM packages into GitHub packages for use by internal repositories also using the @coveo scope

[malaporte]

This PR depends on this other one to be merged and published first: coveo/semantic-monorepo-tools#189

Some of our repos use internal NPM packages published on GitHub Packages under the @coveo scope. For these we need to override the registry for that scope to the GitHub one, but this breaks when loading @coveo-scoped public packages from NPM. Since we can't change the scope for GitHub (it has to be the same as the org), there is not much we can do easily ... besides double publishing our few public packages. So here goes.

https://coveord.atlassian.net/browse/KIT-2806

[github-actions]

Pull Request Report

PR Title

❌ Title should follow the conventional commit spec:

(optional scope):

Example:

feat(headless): add result-list controller

Bundle Size

File	Old (kb)	New (kb)	Change (%)
case-assist	194	194	0
commerce	286.3	286.3	0
search	363.8	363.8	0
insight	314.6	314.6	0
product-listing	304.6	304.6	0
product-recommendation	167.9	167.9	0
recommendation	204.7	204.7	0
ssr	332.4	332.4	0

[louis-bompart]

lgtm, tho don't forget to update semantic-monorepo-tools

[btaillon-coveo]

Unfortunately, I'm not sure this would publish successfully, since our workflows set NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}.

It looks like something more may be necessary to allow authentication to GitHub Packages for packages published to GitHub Packages. Haven't looked too deep into it, but appending the secrets.GITHUB_TOKEN to .npmrc only for the GitHub registry (similar to what they do in https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#authenticating-with-a-personal-access-token) may be a good solution.

Even better, maybe it's possibly to add the token as an option to the publish function?

[louis-bompart]

Good catch @btaillon-coveo, but I think we should follow https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-npm
So instead, in release.yml, let's add a setup-node w/ the git registry and github token. just have to run phase 2 then and gg .

Won't even need to modify the JS files.

[malaporte]

Good catch @btaillon-coveo, but I think we should follow https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-npm So instead, in release.yml, let's add a setup-node w/ the git registry and github token. just have to run phase 2 then and gg .

Won't even need to modify the JS files.

Sounds pretty neat! I've made some changes around this, but tbh I'm not sure what is the kosher way to test it. Should I try to publish a dummy release?

[btaillon-coveo]

Good catch @btaillon-coveo, but I think we should follow actions/setup-node@main/docs/advanced-usage.md#publish-to-npmjs-and-gpr-with-npm So instead, in release.yml, let's add a setup-node w/ the git registry and github token. just have to run phase 2 then and gg .
Won't even need to modify the JS files.

Sounds pretty neat! I've made some changes around this, but tbh I'm not sure what is the kosher way to test it. Should I try to publish a dummy release?

If you want to test it

You could temporarily bring back the test setup that I removed here: #2924

This setup was running Verdaccio as a local registry for testing, and was updating .npmrc to set the registry.

You could run yours in prbot instead of masterbot, and you could move the registry config elsewhere than npmrc.

Here's the setup I was using to test in a PR (in addition to those removed from #2924): be08cb6

Otherwise

This may be overkill just to test it. May be better to YOLO and just 🤞

[malaporte]

Yolo'ing this to test in production :brace: