Quoting the release notes:

At a high level, the breaking changes in this release fix some long-standing issues with the design of esbuild's incremental, watch, and serve APIs. This release also introduces some exciting new features such as live reloading. In detail:

• Move everything related to incremental builds to a new context API
• Allow using watch and serve together
• Support “live reloading” through server-sent events
• Add built-in support for HTTPS
• Better support copying index.html into the output directory
• [...]

Tobias Koppers, the creator of Webpack, shares the plans for Turbopack (“incremental bundler and build system optimized for JavaScript and TypeScript”). Highlights (quoting the blog post):

• Turbopack’s alpha is purpose-built with improving the developer experience for next dev. Once we’ve reached feature parity with the Next.js 13 dev server, we’ll use next build to work on building for production.
• In the future, we will support other frameworks so developers everywhere can enjoy the Turboverse using a plug-in architecture.
• Improving developer insights are also on the roadmap for Turbo, allowing you to create statistical summaries about your build, lint to point you to build optimization opportunities, and analyzers to give you deeper insights.

Topics:

• Website redesign
• Preview release of the new configuration system
• Updates to support ES2022
• Project kickoffs
• Income review
• Expenses review
• Supporting our dependencies and ecosystem
• Looking forward to 2023

Quoting the blog post:

Once a promise is rejected, you have until just-after the next processing of microtasks to handle that rejection, else it may count as an unhandled rejection (“may”, because there's a little bit of wiggle room with task queuing).

Unhandled rejections are problematic. [They] are a bit like uncaught errors, in that they cause the entire program to exit with an error code in Node and Deno.

This post explains where unhandled rejections can occur and how to prevent them.

[Quoting the proposal:] One example of how these keys may be used (remember, this proposal does not specify how the keys are to be used) is within package.json files for projects hosted on npm.

The following package.json file demonstrates a library that exports seperate outputs for Node.js and Deno, as well as specifies which versions of each runtime it supports.

{
    "name": "the-library",
    "version": "1.0.0",
    "exports": {
        "node": "./dist/node/index.js",
        "deno": "./dist/deno/index.js"
    },
    "engines": {
        "node": ">=16",
        "deno": ">=1.10"
    }
}

[node and deno are runtime keys.]