v2 migration

[pi0]

Note

This is a tracker issue for H3 v2 release. You can try with h3-nightly@2x

Migration guide:

• https://github.com/unjs/h3/blob/main/MIGRATION.md
• https://main.unjs-h3.pages.dev/migration

[AaronDewes]

Why did you stop using destr? It's prevention of prototype pollution seemed quite useful.

[pi0]

@AaronDewes mainly for bundle size. But i am up to add a replacement util for safe read (#819, feel free to make a PR for it!)

[magne4000]

What would you think of the following approach to handle Response manipulation, now that standard web Response is the de-facto representation?

defineEventHandler({
  handler(...),
  // Here response type would always be Response
  onBeforeResponse(event, response: Response) {
    // We can then edit the response headers
	response.headers.set('X', 'Y');
    // Or even return a new one?
    return new Response(...);
  }
});

// Another approach: Update EventHandler definition so that we can return a Response Handler
defineEventHandler(event => {
  // return a Response handler
  return (response: Response) => {
    response.headers.set('X', 'Y');
    return response;
  }
});

The benefits I see are:

• Make most of Response utils deprecated, streamlining even more the v2 approach.
  • I'm working on a universal lib that would provide the same functionalities (i.e. manipulate Request and Response objects).
• Allow tool authors to declare their middleware once in a universal manner, and have h3 (or any other server) ingest it without overhead.

[pi0]

@magne4000 With #829 h3 will be web-first with event.response.headers to allow modification of headers. Creating multiple Response objects for middleware might have performance overhead and h3 (v2) by design expects explicit return for body, other partials can be set via event.response and Web standard APIs. Once landed, would love to hear your feedback.