-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Drop node v12 support #4279
Comments
So I haven't given much credence to this, beyond listing some of the stuff we could possibly use with this. I will try to find some concrete examples of how this can make Hapi better. The first is that "Top-Level Lines 1365 to 1390 in c2107e9
With top-Level Feel free to come up with other examples where the new features can help. |
"Optional chaining" can simplify existing code wherever we use the pattern Line 607 in c2107e9
|
"Private class methods" allows us to hide methods from public objects in a simple to use manner. This means we can better control the public API and plugins can no longer use such private APIs. Eg. we don't risk the private |
"Nullish coalescing" is especially useful when extracting default values from passed options and can often work better than the Eg. here is an obvious example, where it would actually fix a weird inconsistency when the timeout is Line 395 in c2107e9
=> options.timeout = options.timeout ?? 5000; But this is a tricky change, as the
options.timeout ??= 5000;
Edit: The ??= syntax requires node v16. |
Lines 359 to 377 in c2107e9
Edit: while it can make the code simpler, it will also require extra processing since |
Thanks for the examples Gil. I believe Eran already used private class methods somewhere in the org already. |
No, only private instance fields, which is supported in node 12 but was still not fully part of ES spec when we started using it. Btw, I would guess that private class methods can allow (slightly) more efficient interpretation / compiled code, since V8 can rely on that the methods never changes. |
Yeah you're right, my bad. I read your initial comment too fast. 😅
That would make sense indeed. |
I added This is not only interesting for simplifying internal processing, but also to extend the hapi API itself. Eg. handler(request, h) {
return Util.promisify(Fs.readFile('/some/file', { signal: h.aborted }));
} Then if a client closes the request before the payload has been fully delivered, hapi can trigger the |
Very cool, thanks for surfacing this. |
Another one: we should move to checking |
I did not mention ESM modules. While I think hapi should definitely support these (for user plugins, when imported, and for testing in Lab), I don't think there is an advantage to convert all the implementation to use it. The place where it makes most sense, is for modules that are likely to be used browsers. It would enable eg. much of Hoek to be imported directly without transpiling. We should however consider how to best interoperate with it. Eg. by removing default exports in public API's. |
I believe ESM may merit a thread of its own. But I personally would like to see hapi provide proper ESM support, and also would like to see it remain written in CJS. |
So how to tackle this? Most of this can be converted internally without any user-facing changes and essentially only require an updated minimum version of node. Then the actual implementation can be sorted along the way. There are however a few of the features that could require breaking changes to implement, and would therefore best be included in the release that changes to require node 14. These are:
As such, any work on this should probably focus on the above. |
Resolved with v21 #4386 |
Support plan
Context
What problem are you trying to solve?
Allow to develop hapi and modules using more current node.js and javascript APIs and features. v12 is in maintenance mode and support ends 2022-04-30.
New JS features we can use:
?.
).a ?? b
).this.#privateMethod()
).WeakRef
support.From node 14 (LTS with v14.15.0) we get:
await
support.stream.pipeline()
.Fs.rm()
method.If we require v14.17+, we could also sneak in:
AbortSignal
support in node APIs.Do you have a new or modified API suggestion to solve the problem?
N/A.
The text was updated successfully, but these errors were encountered: