New owner for broofa/node-uuid?

[broofa]

I'm not giving this repo the love it deserves. Who would be the best person(s) to hand this off to?

@defunctzombie, from what I can tell you have the most popular fork at this point. Thoughts?

[defunctzombie]

@broofa thoughts are as follows:

1. Determine the API difference between this repo and my fork. If the differences are negligible then we can see which repo contains what fixes (iirc my fork exists because some crypto and browser fixes went into it).
2. Once we determine the codebase we want to use, hand it off to the node.js foundation https://github.com/nodejs. I think uuid is a simple and "core" enough module that the project itself could be the owner of it because I too don't actively work on the uuid fork all that much (since the code doesn't need active changes).

/cc @mikeal @bnoordhuis @rvagg

[broofa]

That seems reasonable to me. As you say, the differences should be minimal. The master branch has been pretty stable for a while. I've got a v2.0.0 branch that I was messing around with a while back trying to figure out how to restructure code so it'd be possible to add v3 + v5 support w/out bloating things in the simple case (e.g. where someone just wants v4 uuids)... but that's only half-done, so not worth worrying about.

If nodejs folks are willing to pick this up, I'm more than happy to hand off.

[bnoordhuis]

Not speaking ex cathedra but I don't expect that the Foundation would be open to taking over maintenance. We aim to be neutral first and foremost but adopting a module is inevitably seen as picking a winner.

[broofa]

I don't think there's a "winner" to be picked here. At least, not between the repos that @defunctzombie and I maintain. I'm sure he and I can merge our two versions back together in a way that resolves any conflicts (right?)

... or are there other uuid modules out there you're worried about, @bnoordhuis?

[tracker1]

Could always:

npm deprecate node-uuid@"<= 1.4.7" "npm uninstall --save node-uuid && npm i --save uuid"

[vdh]

@broofa @defunctzombie So is it likely that this merge will eventually end up migrating over to the uuid package name? It feels like a bit of a misnomer to have the node- prefix on a package that can be run in either node or browser environments.

It would also help clear up issues like request/request/pull/2182 about which package name will become the new "official" uuid package.

@broofa One fairly easy way to reduce bloat that comes to mind is Babel/Webpack's "tree shaking" functionality. If the v1/v3/v4/v5 functions were split into individual source files, that would be a fairly cheap way to make it easier for others to optimise their builds (assuming people who care about optimisation already use a build system). Of course, the trade-off being that the ES5-compatible uuid.js file would then have to be built via a build script.

[bnoordhuis]

... or are there other uuid modules out there you're worried about

The existence of an "official" uuid module may discourage competition. Some would say that is a good thing but I speculate the Foundation would rather not go there.

[defunctzombie]

@vdh yes, the intent would be to use the uuid package name.

[danieljuhl]

As it seems like the foundation is probably not that much into adopting a module like node-uuid/uuid, would it make sense to look at an intermediate solution to get the project on track.

The primary thing seems to be migrating node-uuid and uuid. Is it possible under one of the current owners, or do we need to find another owner to proceed with this task? In case we need to find another owner, our organisation (github.com/kodyl) is willing to adopt the project to get it back on track. In case the foundation is up to adoption at a later point we can pass it on to them.

[broofa]

FYI, I've added @defunctzombie (Roman) as a contributor here, and collaborator on NPM.

Roman, I think it would be great to unify these modules. The one problem I see - and it's the main issue I've struggled with trying to move this code forward - is that node-uuid/uuid.js can be dropped into a browser without any packaging or module loading system needed. This makes it super-versatile, but anyone doing that - using the code "bare" - is very sensitive to dependency size and structure. That you're fork has gotten away from this issue is refreshing, but also problematic as far as merging our projects back together. I'm not sure how best to support the audience that just wants to do <script src="./uuid.js"> ... or if that's even worth worrying about at this point.

My $.02

[defunctzombie]

@broofa Thank you, here is the plan I propose. If you are good with it, I will begin the transition.

1. Create a new repo under https://github.com/kelektiv called node-uuid and push the latest version of (defunctzombie/node-uuid) there (adding you and I as collaborators). I do not select this because it is my version but because I think the uuid.js file in that version is a simpler file to maintain (avoids browser boilerplate and allows js packaging system(s) to take care of providing the browser rng shim via package.json browser field specification. If you think this is incorrect or there are patches on broofa/node-uuid which supercede the defunctzombie fork please advise on preference.
2. Update node-uuid on npm to add a deprecation notice so that installing the module will tell people to just install the uuid module. Under no circumstances will we remove node-uuid from npm as this would cause unnecessary breakage.
3. Since the repo under kelektiv is not a move of either defunctzombie/node-uuid or broofa/node-uuid, update the README files of both projects saying that the project now lives at kelektiv/node-uuid. Close any issues or PRs in both projects and disable the issue feature in both projects. It is important that neither project on github is outright deleted as it should remain a reference for the appropriate past version of a module someone may install.
4. Add a section to the new repo readme on how to use one of the many npm based CDNs (https://unpkg.com/#/) for folks that just want a copy/paste solution for their script tags without learning how to use a package builder (altho we will still recommend a package builder for anything that goes beyond prototype stage).

[defunctzombie]

Create a new repo under https://github.com/kelektiv called node-uuid and push the latest version of (defunctzombie/node-uuid) there (adding you and I as collaborators). I do not select this because it is my version but because I think the uuid.js file in that version is a simpler file to maintain (avoids browser boilerplate and allows js packaging system(s) to take care of providing the browser rng shim via package.json browser field specification. If you think this is incorrect or there are patches on broofa/node-uuid which supercede the defunctzombie fork please advise on preference.

Also acceptable alternative to this is to move broofa/node-uuid to the org and then apply all the changes from defunctzombie/node-uuid wholesale. This will preserve the stars and repo followers (since broofa/node-uuid has more).

[broofa]

That all sounds good to me.

Can you provide some background on what/who https://github.com/kelektiv is? My apologies if I should know, but this is the first I've heard mention of that Github account, and there's zero info on the profile page.

[broofa]

... I know this goes without saying, but the top priority here has to be simply, "Don't break anything for the ~7K projects that depend on node-uuid and uuid, collectively". :-)

Re: moveing node-uuid, I'm fine with that... I'd just like to know something about who the owning person/organization would be before giving the final go-ahead.

[defunctzombie]

Can you provide some background on what/who https://github.com/kelektiv is? My apologies if I should know, but this is the first I've heard mention of that Github account, and there's zero info on the profile page.

Apologies, should have also done that. It is an organization @ncb000gt and myself created to collect some of our more highly used node modules for easier contributor access (personal github repos don't allow more than the owner to be an admin or invite others). We have so far moved bcrypt and cron modules to it.

[broofa]

Cool, thanks. So, one last thought. If broofa/node-uuid moves to kelectiv and becomes the repo on which active development takes place, where would maintainence development on node-uuid take place should that be necessary? I know we'll be deprecating it, but you never know ... :-)

I guess a node-uuid branch would be sufficient. Does that seem reasonable?

[broofa]

Hmm. Looks like I need admin rights to kelektiv to initiate the transfer...?

[defunctzombie]

@broofa I think a branch would be adequate.

[defunctzombie]

@broofa please email me and we will coordinate the transfer

[broofa]

Transferred to kelektiv. Go with grace. :-)

[LePoli]

npm WARN deprecated node-uuid@1.4.7: use uuid module instead
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated node-uuid@1.3.3: use uuid module instead