Add a default export with human readable error #418
Conversation
Previously doing `require('uuid')` gives you a
uuid is not a function
Error; which is frustratingly confusing. Throwing a human readable
error with an actionable fix in the message will make upgrading uuid
a lot simpler.
|
Use of the default export was already discouraged since version 3.0.1 of this library which was release in November 2016. I admit that the default export was never formally decorated with a deprecation warning but it was a deliberate choice to remove the default export, as documented in https://github.com/uuidjs/uuid#default-export-removed I'm reluctant of adding back functionality that we started to phase out 4 years ago… |
|
I think that it would be a bit strange to export a default function that just throws, although I do understand your frustration. I'm not sure if this has been discussed, but maybe another approach would be to ship TypeScript typings with the package, in that case your IDE should show an error as soon as you try to call the default import:
(note that this works even though I'm not using TypeScript here, this is just an ordinary JavaScript file, but the IDE can still read typings from the package and help me) |
|
Has the algorithm for uuidv4 changed in the last 6 years ? I assume the uuid function has had stable behavior for the entire lifetime of the npm package. I respect its deprecated but it was only removed a month or two ago. I’d personally treat this package as frozen and put the default export back. It’s an unnecessary breaking change. If you do not wish to put the default export back at least make the exception it throws better then not a function. Another option is to make the default export only available for commonJS and making the breaking change in ESM. I don’t understand what has changed about v4 between what was published 5 years ago and today that warrants breaking my code. |
|
The v4 algorithm has obviously not changed. The only thing that has changed is that we no longer promote the v4 algorithm as a default export: The UUID RFC does not specify a default. It specifies 4 distinct algorithms and none of them is supposed to be a "default" whatsoever. If you are interested in the pros and cons of having one algorithm as the default export then feel free to read the discussion over at tc39/proposal-uuid#3 where we concluded that it's at least not a very future-proof idea to promote one specific UUID algorithm as a default. We have been actively discouraging the use of the default export since this PR was merged: https://github.com/uuidjs/uuid/pull/159/files (i.e. no more mention of it in the README). We did a major version change from 3.x to 7.x precisely because we made breaking API changes, one of which was the removal of the default export. People who are still using the default export have the option to either update their code or just stick to This package is not "frozen", the ecosystem evolves and e.g. the need for new concepts like ECMAScript Modules arises, so I think it's just natural that this library evolves with the JS ecosystem. Also in the light of a potential inclusion of UUID into the JavaScript language we are working towards aligning this module with the concepts and ideas that come up in the standardization process so that ideally it will become seamless to make use of the new language features once they become available. |
|
Ugh, from reading the standardization thread it sounds like you need NO default export in the module until the standards committee has decided what the default export should be so that you can add it back in the future ... |
Previously doing
require('uuid')gives you auuid is not a function
Error; which is frustratingly confusing. Throwing a human readable
error with an actionable fix in the message will make upgrading uuid
a lot simpler.