Node.js 21

Apparently the idea of only supporting LTS versions of Node.js went down the shitter. New rule will be:

• 3 most recent LTS versions (or to be LTS) are supported.
• Latest non-LTS (never to become) supported until replaced with a new one.

This means Node.js 16, 18, 20 and 21 are supported now.

Then it becomes 18, 20, 21, 22. Then it becomes 18, 20, 22, 23. Then it becomes 20, 22, 23, 24. Then it becomes 20, 22, 24, 25.

Then, you should really just swap to Bun.

Fixes

• Updates uWS to v20.47.0

HTTP error pages

This release bumps uWS to v20.45.0 which adds error codes / pages for:

• 505
• 431
• 400
• 404

This means easier debugging when using proxies, as uWS won't simply respond with a generic RST (which often ends up as a 502 in the proxy), but will instead return proper HTTP error pages / status codes that can be handled & logged properly.

More user error message fixes

This release reverts v20.25.0 since it was quickly found to be a heavily misunderstood and misused mode. This change is backwards compatible, as the flag will simply be ignored.

This release also tweaks the onWritable error message into a warning message that better guides the user to a solution:

Warning: uWS.HttpResponse.onWritable callback should return Boolean. See documentation for uWS.HttpResponse.onWritable and consult the user manual.

It also tweaks the error message from use of deleted uWS.HttpResponse:

Error: uWS.HttpResponse must not be accessed after uWS.HttpResponse.onAborted callback, or after a successful response. See documentation for uWS.HttpResponse and consult the user manual.

Obvious user error messages

This release tweaks the error messages given to users who use the library wrongly. Now they are less technical and more helpful and guides the user to the docs and manual:

On ill-use of uWS.HttpRequest:

Error: uWS.HttpRequest must not be accessed after await or route handler return. See documentation for uWS.HttpRequest and consult the user manual.

On ill-use of uWS.HttpResponse:

Warning: uWS.HttpResponse writes must be made from within a corked callback. See documentation for uWS.HttpResponse.cork and consult the user manual.

Hopefully users will stop reporting these errors as if they were bugs in uWS, and instead read them and go to the docs to solve the problem on their end.

• Updates uWS to v20.43.0

Some corrections to last release. A better warning is now used:

Warning: uWS.HttpResponse writes must be made from within a corked callback. See documentation for uWS.HttpResponse.cork and consult the user manual.

Some fixes to TypeScript definitions have been merged.

Warning of ill-use

This release adds something I have wanted to add for a long time. While the user manual is pretty clear on this, many users don't care to read it. So with this release there is now a in-your-face critical warning for ill-use regarding corking.

This release is backwards compatible, since we only issue warnings, but next major release will make this warning into a forceful termination of your app. This is done, to make it crystal clear that you aren't using uWS.js properly.

On invalid use, you will now get this:

Critical warning: Calling uWS.HttpResponse [.writeStatus, .writeHeader, .end, .write, .tryEnd, .upgrade, .endWithoutBody, or similar] outside of uWS.HttpResponse.cork callback is highly discouraged due to major performance loss! Read the user manual and make the fix.

If you get this warning, fix your app.

Alien tech 👾

This release introduces a new mode of integration; no integration. Setting the environment variable ALIEN_UWS=1 makes uWS run entirely alien to Node.js, on its own separate event-loop. This mode greatly increases performance of uWS.js given the same CPU-time budget, by escaping Node.js's heavy weight AsyncHook feature that always imposes a huge performance penalty to your entire Node.js process, regardless if you actually use it or not. AsyncHook will not be able to track uWS.js callbacks in this mode.

• Updates uWS to v20.40.0.