Determine how to publish npm packages so the 18f org has access

[msecret]

In order for any 18F developer to have permissions to publish an npm package, every npm package 18F publishes should give permissions to the 18F org.

We should also add adding people to the org as part of onboarding.

[jseppi]

Potentially helpful: https://github.com/tmcw/ownership

[msecret]

Starting to do research here, is there a reason we'd want to grant every 18f team member ownership, or could we just give the 18f-devops npm account ownership, and the person who runs that account could grant permissions if needed?

[msecret]

On top of that, I think packages should be scoped to 18f if they should be specific to 18f code, such as a linter configuration or generic front end components, such as @18f/accordion. If the package will be often consumed by people outside 18f, such as WDS, then it shouldn't be scoped to 18f. A good question to ask is: "Does an outside person using this need to know what 18f is to use this package?" In the case of WDS, the answer is no, so it shouldn't be scoped.

[rogeruiz]

@msecret is the idea behind "Does an outside person using this need to know what 18f is to use this package?" imply that the project might be handed off to an owner outside of 18F eventually? Or is it just about an outside person using this need[ing] to know what 18f is being the concern?

✋ I think it'd be good to have a write-up of how to give access to other 18F developers when a project is not scoped to @18f/. I wouldn't mind writing it up using uswds as an example. I'm thinking something along the lines of the rough draft below would be good to include with how to properly scope package using @18f/ in package.json.

---

How to handle non-scoped 18F projects

Some projects shouldn't be scoped with @18f/ in the package.json. These npm packages are often consumed by people outside of 18F. A good question to ask is: Does an outside person using this need to know what 18F is to use this package?.

Because this npm module is not scoped with @18f/, only the original publisher of the package and any contributors that they added explicitly, using the npmjs.com UI, are able to publish to non-scoped 18F packages.

Using the npmjs.com UI to add contributors

Adding contributors manually to a non-scoped 18F package can be done through the website's UI.

Things you'll need in order to add contributors are outlined below:

• author or collaborator access to the node package
• the npm username of the user to be added as collaborator
• an internet connection to the npmjs.com website

Going to the npm package's url

Scroll down to the Collaborator section and hit the + button

Add their npm username and hit enter in the text input.

There are ways to interact with the npmjs.com registry via the npm cli. The access documentation is here. Because adding <scope:team> requires you to have certain permissions on your npmjs.com account like Super admin or Team admin. You can see who has what access by going here while logged into your npmjs.com account.

[msecret]

@rogeruiz for your question: I don't think the concern is that it would be handed off to somebody outside of 18F, it's the latter, a person outside of 18F doesn't need to know about 18F to use the package. For instance, the WDS is a well known project that's used by many people outside of 18F. This is an example of when something shouldn't be scoped.

[adborden]

FWIW, I'm a big fan of automated deployment. It takes a lot of the guesswork out of publishing, and removes little inconsistencies in the resulting package. You can setup npm publishing through CI, some are better supported than others. Travis for example has an npm provider. Org-wide, this would mean that anyone with git push access would be able to publish to npm just by pushing a new tag to github.

[msecret]

Next steps: Add Roger's work into the guide. Add anything else required.