Add export const uuid = v4

Is your feature request related to a problem? Please describe.

For all libraries I use I don’t have to write imports manually in WebStorm. All I have to do just write code like const x = doSomething<ALT + Enter> and it shows me hint Add "import doSomething from XXX'?

With export const v4 I have to write manually import as in manual import { v4 as uuidv4 } from 'uuid';. It’s frustrating.

Describe the solution you’d like

Change v4() name or add one more export as export const uuid4. So after import it would be very clear what is it about and why.

Describe alternatives you’ve considered

• Writing manually 😦
• Adding somewhere utils/uuid.ts with

export { v4 as uuid4} from 'uuid'

[sholladay]

Sort of, @syabro. It’s the same in that I showed an alternative way to use the v4 function, via namespace import instead of as a named import. It’s the same function, but accessed a different way. In my opinion, the namespace import is much less ugly.

It could be simplified further by attaching the functions as properties of the default export object. Then you’d be able to do this:

import uuid from 'uuid';

uuid.v4();

That would be the cleanest syntax.

[ctavan]

Thank you for raising this @syabro

I do have to admit that personally I’m also not super happy with the current named exports. They have mostly historic reasons:

1. When this library was initially released in 2011 for Node.js there was no notion of named exports and not even object destructuring, and in addition this library only supported v4 UUIDs, so the API surface was:

   var uuid = require('uuid');
   uuid();
   

2. Then at some point additional algorithms were implemented and the default export merely became an alias for uuid.v4(). IIRC that was still before Node.js 6.0 so object destructuring assignments like const { v4 } = require('uuid') still weren’t really a thing:

   var uuid = require('uuid');
   uuid.v4();
   uuid.v1();
   // etc…
   

3. Then uuid started to be used in browsers as well and treeshaking became an issue, hence we started encouraging deep imports. But since these deep imported files still only exported a default export that local import names weren’t really an issue either:

   var uuidv4 = require('uuid/v4');
   uuidv4();
   

4. So only with the migration to ECMAScript Modules (ESM) and named exports the import names became somewhat predetermined.

   import { v4 } from 'uuid';
   v4();
   

The reason we kept the v4, v1 etc. names when moving to ESM was the idea of keeping the API change as small as possible.

I do admit though that in the ESM world we live in by now requiring aliasing when importing one of the algorithms is really not ideal and at least I didn’t really consider that aspect enough when doing the migration to ESM.

All that said I believe this might be a good chance to get rid of the confusing v1, v4, … naming entirely. After all it seems to be causing more harm than good, see discussions in https://github.com/tc39/proposal-uuid/issues/3 and this analysis.

So instead of sticking to these names I suggest to export the algorithms with more telling names, like discussed in https://github.com/tc39/proposal-uuid/issues/3#issuecomment-544190284. Something like:

v1() -> timeUUID()
v4() -> randomUUID()
v3() -> md5UUID() // (or nameUUID()?)
v5() -> sha1UUID() // (or nameUUID()?)

An alternative would obviously be to export uuidv4() instead of v4(), this naming would be similar to what Python does

Thoughts?