Repository navigation
npm package management for node.js foundation modules #211
Description
We have a number of modules under the node.js foundation including:
https://github.com/nodejs/node-report
https://github.com/nodejs/node-inspect
and there may be others in the future.
I've looked at a few options of how we might manage the publishing of these modules which are listed below. My recommendation is Option 1:
-
Option 1 - create a user called something like "node-foundation" who we always add as one of the collaborators with admin rights and for which the password is maintained by the build workgroup. We would then add individuals as collaborators who can also publish. Generally, a module push could be done by the additional collaborators. In the cases were collaborators other than "node-foundation" cease to be active, the build workgroup would provide continuity by using the node-foundation user to add additional collaborators who would have the ability to push the module. The node-foundation user could also be used to remove collaborators if that was ever necessary.
-
Option 2 - use the organization feature in npm. This gives use better management of a team to manage the modules but means the module would be scoped. I don't think we'd necessarily want the scope in the name, and I was told that it also prevents shrinkwrap from working, which sounds like a deal-breaker. Organizations are also a paid feature so we'd either need to budget modest funds or ask for the feature for free.
-
Option 3 - Create a user called something like "node-foundation" and ensure it is used for all publishes. We'd only publish through CI jobs so that access to the password would be limited.
-
Option 4 - Create a user called something like "node-foundation" and ensure it is used for all publishes. In this option we'd share the password so that the people who need to do publishes can do them directly.
An addition to Options 1, 2 and 4 would be to work on CI jobs so that publishes could be done more easily and consistently. I believe we should plan this in regardless of the option chosen.
In searches on npm.js, the collaborator who last pushed the module shows up. In the case of Option 3 and 4 (or for any of them if we consistently use a CI job for publishes) that would always be the node-foundation user. All collaborators are listed in alphabetical order on the main page for the module.
Activity
ljharb commentedon Feb 15, 2017
Scopes should work fine with shrinkwrap on npm3+, as far as I know.
Option 2 would be the cleanest, Option 1 is next, Option 4 is last. Option 3 would remove the human component from publishing, so I'd discourage it.
jasnell commentedon Feb 15, 2017
Option 2 is likely the best option moving forward but does not necessarily help with things that are already published and used without that scope (e.g.
readable-streams). A hybrid of Options 1 and 2 are likely the best choices.sam-github commentedon Feb 16, 2017
We use npm2 in 4.x, which is LTS, I don't think we should use a strategy that causes pain to LTS users, which means avoiding scopes until all LTS releases support them.
rvagg commentedon Feb 23, 2017
TSC discussion today: I'm advocating for option 1, we do something like that @ NodeSource, and Michael has feedback that the StrongLoop team does something similar. i.e. publish packages as normal, under normal user accounts but always add an official NF user account for publish access so that if we need to, we can use the NF user to get access to it.
jasnell commentedon Feb 23, 2017
+1 for option 1
bnoordhuis commentedon Feb 23, 2017
I have a mild if possibly irrational preference for option 3: one NF account coupled with CI.
A single NF publisher looks official (less confusion about whether it's a NF package or not) and the CI would be a backstop for accidental or bad publishes, hopefully.
ljharb commentedon Feb 23, 2017
For an anecdotal data point, at Airbnb we go with option 1 (https://www.npmjs.com/~airbnb) and I've not heard any complaints or commentary about the "officialness" of any of our packages.
Separately, we stick with the philosophy that publishes must always be manually initiated by a human as a backstop against mis-labeling semver ranges, since publishes are irrevocable.
mhdawson commentedon Mar 10, 2017
Ok from what I see we have +1 for option 1 from myself, jasnell, rvagg along with agreement through comments or thumbs up from ljharb and sam-github.
@bnoordhuis your preference was mildly for 3, but I think given the rest of the input unless you want to object to 1 instead, I'll move forward with option 1 as a start. I still think we should also look at supporting publish with the CI but don't want to make it a blocker to moving forward for now. If and when we get the CI jobs in place we can move to 3 if we think that makes sense at the time.
I'll look to create the npm user mid next week and co-ordinate with @jbergstroem to get the password added to the secrets rep. Once thats done we'll move on to having that user added to the modules in npm.
mhdawson commentedon Mar 14, 2017
Ok, created user
nodejs-foundation, next step is to get password into secrets repo.mhdawson commentedon Mar 14, 2017
Would also be good to figure out how to set avatar to be the node logo.
gibfahn commentedon Mar 15, 2017
@mhdawson https://www.npmjs.com/~nodejs-foundation seems to have
build@iojs.orgas an email address. Is there anodejs.orgequivalent we could use?mhdawson commentedon Mar 15, 2017
@gibfahn I had looked for that and did not find any nodejs.org emails in the alias list. I thought I'd go with what was there and then update when I figured out if we had any nodejs.org equivalents. @rvagg do we have nodejs.org emails as well ?
jasnell commentedon Mar 15, 2017
@mikeal ... What's the current status on being able to use
@nodejs.orgemail aliases?gdams commentedon Mar 15, 2017
@mhdawson setting the avatar on npm should just a case of creating an account on gravatar with the same email address and it should pull it in. I believe that's how I changed mine
14 remaining items
jbergstroem commentedon Apr 18, 2017
@mhdawson there's a few build related ones we have as part of the build repo. They're currently not packaged at npm.
gibfahn commentedon Apr 18, 2017
@jbergstroem would it be worth pushing them to npm? If not then this is done.
Except for trying to find out if @chrisdickinson is willing to give us
@nodejs.joaocgreis commentedon Apr 18, 2017
Should https://github.com/nodejs/node-gyp add the user as well? (cc @nodejs/node-gyp)
bnoordhuis commentedon Apr 18, 2017
I'd take care of that but it looks like the npm registry is broken again, I get a 500 trying to add or remove owners.
mhdawson commentedon Apr 20, 2017
Still need to get nodejs-foundation user added to node-gyp, nodejs-dist-indexer, nodejs-nightly-builder
mhdawson commentedon Apr 20, 2017
Checked and there is still some discussion on how to manage the password in the secrets repo as well.
bnoordhuis commentedon Apr 21, 2017
nodejs-foundation is now a proud (co-)owner of node-gyp.
gibfahn commentedon Apr 23, 2017
https://twitter.com/isntitvacant/status/856194444248326145 from @chrisdickinson
@Fishrock123 and @mhdawson any chance you two could get together and convert
@nodejs-foundationto@nodejs?Fishrock123 commentedon Apr 23, 2017
If that is the favored path then sure.
mhdawson commentedon Apr 25, 2017
I'm fine with any name so if you can give me enough access so that I can set a master password, I'll do that, store that in build secrets repo and then go through and add the new user (I guess org will need to look to see if that affects anything) to the relevant modules.
jasnell commentedon May 30, 2017
Does this issue need to remain open?
@mhdawson ... what may be helpful is a write up added to the repository about how to use the foundation npm account.
mhdawson commentedon May 31, 2017
@jasnell this is what I was waiting to land and is the doc: nodejs/build#670
jasnell commentedon May 31, 2017
oh nice... sorry I had missed that PR. Once that lands we can close this issue.
mhdawson commentedon Jun 2, 2017
Just landed nodejs/build#670, closing.