docs: troubleshooting install issues

[oli-hivemq]

Add a troubleshooting section for authorization issues when trying to install this library from another repo.

[tolumq]

Hello @oli-hivemq,
Thank you for adding this, it definitely would save a lot of new users some time.

However, I think using .npmc might expose the user's token into git unless it is used through an environment variable (which might complicate things) for the CI build, or removed from git which is another using too.
Saving the token in their .bashrc or .zshrc might be another option
What do you think?

[antpaw]

If this meant to solve issues on CI/Jenkins side:

• we should not store plain tokens in open files
• usually our internal systems already have access tokens, at least that's how it was in hivemq-enterprise
• I've build a system that allows to set the token securely, it used gradle (it is hivemq-enterpise main build tool anyway) hit me up if you need more details

[oli-hivemq]

Thanks @tolumq & @antpaw, I updated the README based on your comments

[antpaw]

Last minute request:
can we rename NPM_TOKEN to GH_NPM_TOKEN (GH stands for github) because there could be more package hosting repos down the road and it makes it more clear.

[tolumq]

Last minute request: can we rename NPM_TOKEN to GH_NPM_TOKEN (GH stands for github) because there could be more package hosting repos down the road and it makes it more clear.

@antpaw Can you kindly clarify what you mean by this?
I think having one token to handle access to our Github registry should be enough, since they would all be on Github (unless we have plans of moving the private libraries from Github which I don't see us doing anytime soon).

[tolumq]

LGTM

[oli-hivemq]

@antpaw what about splitting step 2 (currently about saving the token in an env variable) into 2 paths:

• locally -> NPM_TOKEN
• for CI -> GH_NPM_TOKEN
  ?

[antpaw]

@tolumq @oli-hivemq what I essentially mean is that NPM_TOKEN could refer to different registries (eg github.com or npmjs.com or somewhere else). Putting a GH prefix makes it more clear, locally and on ci.

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#considering-cross-repository-access gihub refers to it as GITHUB_TOKEN which is also confusing in a setup with different technologies

[oli-hivemq]

@tolumq @oli-hivemq what I essentially mean is that NPM_TOKEN could refer to different registries (eg github.com or npmjs.com or somewhere else). Putting a GH prefix makes it more clear, locally and on ci.

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#considering-cross-repository-access gihub refers to it as GITHUB_TOKEN which is also confusing in a setup with different technologies

I see. That's a good point. In this case, what the doc could say is:

1. save your token in an environment variable (e.g. in your ~/.bashrc or ~/.zshrc):

UI_THEME_NPM_TOKEN=YOUR_GENERATED_TOKEN

2. add a line to .npmrc:

//npm.pkg.github.com/:_authToken=${UI_THEME_NPM_TOKEN}

Or keep it as it is and add a note to the doc mentioning your point @antpaw

[antpaw]

We will have more packages that are shared, UIShell has a package, XSD-Forms is a package. Creating the same token with different var names feels "off," i rather keep it as is.