feat: stable types node and exit hooks

[jkomyno]

See Slack thread.
Fixes #17127.

This PR:

• aligns the devDependency on @types/node for the public Prisma packages to v14.18.42.
• fixes related type issues that emerged in ExitHooks.ts after stabilising the @types/node versions

[socket-security]

New dependency changes detected. Learn more about Socket for GitHub ↗︎

---

👍 No new dependency issues detected in pull request

Bot Commands

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@* or ignore all packages with @SocketSecurity ignore-all

Pull request alert summary

Issue	Status
Install scripts	✅ 0 issues
Native code	✅ 0 issues
Bin script shell injection	✅ 0 issues
Unresolved require	✅ 0 issues
Invalid package.json	✅ 0 issues
HTTP dependency	✅ 0 issues
Git dependency	✅ 0 issues
Potential typo squat	✅ 0 issues
Known Malware	✅ 0 issues
Telemetry	✅ 0 issues
Protestware/Troll package	✅ 0 issues

---

📊 Modified Dependency Overview:

🚮 Removed packages: @types/node@12.20.55, @types/node@14.14.21

[codspeed]

CodSpeed Performance Report

Merging #18899 feat/stable-types-node-and-exit-hooks (97ca7de) will not alter performances.

Summary

🔥 0 improvements
❌ 0 regressions
✅ 3 untouched benchmarks

🆕 0 new benchmarks
⁉️ 0 dropped benchmarks

[geoextra]

For me this fixes an issue which currently prevents me from deploying to Northflank using heroku/builder:22 in the context of a SvelteKit build after upgrading from Node 19 to 20.0.0:

TypeError [ERR_INVALID_ARG_TYPE]: The "code" argument must be of type number. Received type string ('SIGTERM')
     at process.set [as exitCode] (node:internal/bootstrap/node:124:9)
     at process.exit (node:internal/process/per_thread:188:24)
     at process.<anonymous> (/workspace/node_modules/@prisma/client/runtime/library.js:99:2170)

If I build the app on a local machine I don't get this error. This should relate to the breaking changes in this Node pull request. Should I still open an issue for this?

[Jolg42]

People might rely on the old exitCode, not sure if we want to do this change in a standard release?

[jkomyno]

Considering this is a direct consequence of Node.js changing its behavior, that's not up to us.
Afaik, as long as we don't turn a 0 exit code into another number, everything's fine

[SevInf]

I am with Alberto on this, right now, you applications exit code changes to 0 if you set our beforeExit hook, this change would restore them to what they are by default.

[Jolg42]

Not sure about this since it was always 0 until this PR.
Also, we would at least need a test for this? It's an important bit that is still untested based on the CI run here?

[SevInf]

It was not always 0. We set our signal handlers only when you add beforeExit event listener. If you don't do it, exit code will be default one, 128 + signal.

[Jolg42]

Which means it was always 0 for people using the beforeExit event listener 😄

[jkomyno]

Sigh, tests are failing due to unrelated snapshot changes