Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use built-in crypto.randomUUID #156

Closed
jonathansamines opened this issue Oct 1, 2021 · 2 comments
Closed

Use built-in crypto.randomUUID #156

jonathansamines opened this issue Oct 1, 2021 · 2 comments
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Milestone

Comments

@jonathansamines
Copy link
Contributor

Support plan

  • is this issue currently blocking your project? (yes/no): No
  • is this issue affecting a production system? (yes/no): No

Context

  • node version: n/a
  • module version: n/a
  • environment (e.g. node, browser, native): node
  • used with (e.g. hapi application, another framework, standalone, ...): hapi application
  • any other relevant information: n/a

What problem are you trying to solve?

Yar makes use of uuid.v4(). Given that dropping support for Node 12 is being proposed at hapijs/hapi#4279. Is it worth considering to use the Node's built-in support for UUID v4 (crypto.randomUUID)?

Do you have a new or modified API suggestion to solve the problem?

Not necessary, change would be an implementation detail, but support for Node 12 must be dropped. It is also worth mentioning that crypto.randomUUID is only available from Node 14.17

@jonathansamines jonathansamines added the feature New functionality or improvement label Oct 1, 2021
@kanongil
Copy link

kanongil commented Oct 2, 2021

I think it makes sense to require node 14.17+. It has been out for close to 5 months, and likely more than 6 once this change would be published. Hapi is already known for aggressive node runtime requirements.

@Nargonath
Copy link
Member

It would make sense indeed. Thanks @jonathansamines for raising this. Usually it's pretty straightforward for users to increase their minor/patch versions of Node so I'd expect this version requirements not to be pretty problematic. We'd have to flag it breaking changes though since we're dropping Node@12 by using it.

@Nargonath Nargonath added the breaking changes Change that can breaking existing code label Oct 11, 2021
@devinivy devinivy added this to the 11.0.0 milestone Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

4 participants