What's the difference between "uuid" and "node-uuid" modules?

[ryanlelek]

At the risk of digging up skeletons,

I noticed @broofa is a contributor to both projects and the "uuid" repository by defunctzombie was forked from this repository by broofa.

They look similar, but the versions are very mismatched.
Is there a particular benefit of using one or the other? Why did defunctzombie fork?

Ryan

Reference:
"node-uuid" : https://github.com/broofa/node-uuid
"uuid" : https://github.com/defunctzombie/node-uuid

[joepie91]

Currently, this module has unsafe default behaviour (#118) in both Node.js and browsers, whereas the defunctzombie fork only has this behaviour in browsers. Therefore, if running in Node.js, you should be using the fork.

[ryanlelek]

Thank you @joepie91 for your vigilance in detecting the fallback and providing your insight on which version to use. Will switch to the defunctzombie fork

[coolaj86]

The issue has been resolved, but it begs the question if we should just deprecate this and put in the README.md that uuid is being more actively maintained. It looks like uuid has already fixed many of the issues that were outstanding here.

Thoughts @broofa?

[broofa]

Well, I have some half-baked ideas around what v2 of this lib should look like - specifically, around making it more modular so dependent code can generate a particular version of uuid without having to include unnecessary code for other versions of uuid. E.g. V4 uuid generation shouldn't require the [large amount of] code need to shim SHA1 hash generation that v5 uuid creation depends on (which is why this lib doesn't currently support v3 or v5 uuid creation). I tinkered with this awhile ago on the v2.0.0 branch but never rears a point I was satisfied with, and life events have "de-prioritized" my interest in this... But, yeah, in an ideal world Id still like to see this happen.

I've no idea what plans, if any, the 'uuid' project has for the next major version. But that would seem to be the main discriminator for what to do with these projects.

My $.02. I'm open to suggestions, and will grudgingly admit my absentee-landlord status here warrants the 'uuid' fork... And apologize for that.

[myitcv]

I've no idea what plans, if any, the 'uuid' project has for the next major version. But that would seem to be the main discriminator for what to do with these projects.

Agreed. To ask this another way, is there a reason node-uuid and uuid can't reconverge back to node-uuid?

cc @vvo @defunctzombie

Also just to throw into the mix... One 'dependency' on the node-uuid package are TypeScript type definitions, the main example being those hosted on DefinitelyTyped. At the moment, type definitions for these two packages are identical in all but the name of the module ("node-uuid" vs "uuid"). Clearly not a showstopper, rather just to flag this dependency.

[vvo]

Hey I think neither me or @defunctzombie have big ideas for the uuid package.

We will gladly give you push access @broofa to the uuid package on npm as soon as we are sure the browser build is working and do not require the crypto module.

That's it I think, otherwise we are good!

[defunctzombie]

I originally forked this because @broofa was unresponsive in claiming and
migrating to the plain uuid name. If that is no longer the case happy to
merge back what makes sense. Also don't really care if there are two given
that this one is under the plain uuid name.

On Monday, November 16, 2015, Vincent Voyer notifications@github.com
wrote:

Hey I think neither me or @defunctzombie
https://github.com/defunctzombie have big ideas for the uuid package.

We will gladly give you push access @broofa https://github.com/broofa
to the uuid package on npm as soon as we are sure the browser build is
working and do not require the crypto module.

That's it I think, otherwise we are good!

—
Reply to this email directly or view it on GitHub
https://github.com/broofa/node-uuid/issues/116#issuecomment-157000681.

[myitcv]

Great.

Apologies, I wasn't actually advocating merging one way or the other (or one name vs the other), rather, I'm just supportive of these two code bases reconverging under one name to make the question of "which one should I choose" redundant.

Thanks to everyone involved for their continued work on this.

[rgbkrk]

Thanks for having a civil discourse about this. I need to trim some of my related projects to only use one or the other of these and keep accidentally using one or the other.

[antialias]

I just submitted pull requests to all the packages in my dependency trees that depended on node-uuid to depend on uuid instead.

• using defunctzombie fork of uuid because node-uuid has been abandoned by developer TritonDataCenter/node-http-signature#57
• using defunctzombie fork of uuid because node-uuid has been abandoned by developer sockjs/sockjs-node#199
• using defunctzombie fork of uuid because node-uuid has been abandoned by developer dfilatov/vow-fs#22
• using defunctzombie fork of uuid because node-uuid has been abandoned by developer request/request#2182

There may be other packages that depend on node-uuid, but that's all there is in my world.

[antialias]

update: one down, three to go

[antialias]

vow-fs switched

[antialias]

node-http-signature switched

[antialias]

Hi @ALL, can I get some support for my PR over at request/request#2182 ? It's the last major package that hasn't switched over to defunctzombie/node-uuid.

[antialias]

@defunctzombie can you add a comment over at request/request#2182 (comment) ? I'm getting resistance from simov on moving request over to your fork of uuid with my pr. I don't think he understands that your fork is the only one under active development and that node-uuid has been abandoned.

[jez9999]

This doesn't seem to have been completely resolved and it's confusing as heck. I guess it's the peril of having a flat npm namespace, but we have two modules "uuid" and "node-uuid". Both of them are probably safe to use, both of them have lots of users, both of them seem to be maintained OK (although the less-maintained one is the one that has more users!)

How do I decide which to use? Flip a coin? If you guys can decide on re-merging, you should do so, and formally deprecate one of them.

[rgbkrk]

@jez9999: Use uuid, as in npm install uuid.

[vdh]

@jez9999 Use uuid, it's been discussed in #142 as the official successor name to both libraries after they eventually get merged back together.

[broofa]

I've added @defunctzombie as a contributor to this project and also added him as a collaborator in NPM.

I'm hoping that will help break this project loose from my lack of attention.

[AlexNasonov]

firebase/polymerfire uses node-uuid btw...

[vdh]

@AlexNasonov How do you know that? I can't even see a package.json in their repo. But aside from that, they should just change over to uuid, it works the same.

[broofa]

@AlexNasonov Are you sure?
Also, what @vdh said.