so, i’ve continued to experiment to attempt to figure out what process could accomplish what i’m after.
first, to clarify what wasn’t completely clear above, i’ve settled on what i think i’m really trying to accomplish with teams:
- a team for org members that only need to consume packages, including private packages, through
npm install (with the latest semantic-release features, this is all humans)
- a team with rights to publish packages (this can now be limited to only our bot account)
based on the conversation above, i decided that making the “developers” team the one with publish rights would currently be the simplest approach, so i moved humans to a new team named “consumers”. the downside that i knew about to this approach is the additional management to move new team members out of the “developers” team and into the “consumers” team. this part isn’t too big of a deal since that happens infrequently and is already a manual process. the part that i’ve finally confirmed is that publishing a new package does not automatically give any rights to teams other than the “developers” team. this is a pretty sensible default behavior, but does mean that some step would need to be taken to grant read access to the team of humans that will be trying to install the package shortly after publishing (since something else will likely depend on it shortly after it is published). additionally, since it seems like granting this access would have to wait until after at least a pre-release version is actually published, it would be difficult to add this as a step to our existing scaffolding script.
long story short, even after spending time attempting to get my head around current behavior, i feel like i still have more unanswered questions than answered ones for how i would ensure the proper access is set for every package under the org. i wasnt able to find much clarification in the docs and even questions asked here are left with a number of maybe’s. i dont say that to suggest anyone should be able to recite all behaviors of the top of their head, but not being able to determine concrete answers adds further discouragement to following through to limit access appropriately.
to be clear, my goal is for the team structure described above to apply to every package under the org. since all configuration is per package, it seems to be far more difficult than in could be to accomplish what seems to be like a pretty simple access rule. this may be a big assumption when there are so many users of npm, but it seems like this would be a very common use case across many teams.
The three steps above would all let you manage “at the org level”, or pretty damn close to that. Sufficiently close that I’m not sure we’d need an additional feature.
while i do think that you are correct that it can technically be accomplished, in practice doing so would be pretty heavy addition to a team that creates new packages regularly. security is a difficult practice to do well, so simplifying doing the right thing would be the reason i think there would be value in a way to apply such a rule consistently across an org rather than per package. might even be an opportunity to structure pricing in a way that encourages even further by charging more for team members that have publish rights than those that only have read access.
i’d love to understand if there are other angles to consider, but even when i consider myself pretty security conscious, i’m having a hard time finding the energy to jump through the hoops that would be required to do this well currently.