I’m building a commercial JavaScript library that I intend to distribute to customers as an NPM package.
Currently I have my pipeline set up to build and deploy to Gitlab’s NPM package registry as described in the guide (npm packages in the Package Registry | GitLab) which works great so far.
As I’m onboarding my first customers I’m a bit uncertain on whether to allow these customers read-only access to the private package registry via an auth token (npm packages in the Package Registry | GitLab) that the customer has to add to the .npmrc file, or if I should publish to npmjs.com as this is what every dev is familiar with.
Publishing it only to the Gitlab package registry has a certain appeal to me as it avoids duplication, and has a more “private” feel to it, which for the moment is preferable for my product. On the other hand, I’m not 100% sure if this will scale well (i.e. is it possible to easily/programmatically generate a new r/o auth token for every customer), and I’m afraid that I’d accidentally open up private infrastructure to the outside world.
I don’t see any problem with generating new read only tokens. You can do that using the Gitlab API: Personal access tokens API | GitLab in which case it wouldn’t be a problem for scaling. You can configure what the access token needs to gain access to for example the read_repository permission would suffice.
If you don’t want the code to be made available, I would simply just have the project run the CI/CD, and then push the package to a different project which will not host code, but just be used for the npm package repository. That way at least you can control what they have access to and what they don’t have access to.
I do something in a similar way with our Gitlab installation to make available our application. I create a generic user - eg: my_project_user which is where I will generate the access tokens for each of the clients. The user my_project_user then is given access only to the project where they will download the package from the registry. The other project where the code is they are not given access to, which means no chance of opening up other repositories by mistake and thus keeping control of everything. Another way would be to create a Gitlab user for each client individually, and then assign them their own access token to this account - not giving them the password to the user account to force them only to use the token. I feel that would be overkill, but also if the client’s email address was added to this user, they could potentially request a password reset and then have the ability to login to the web interface. With the generic user that I mentioned earlier, they wouldn’t be able to since this would have an email address that points to one of our internal emails or a fake email that would never even receive. It would be easier to create tokens under one single user than across dedicated users, at least for me anyway, much easier to script to automate creating new ones when they expire.