v3-migration-guide.md

Version 3 of vercel-deno includes some breaking changes compared to previous versions. Read below to see how to update your code to be compatible.

Unified Request Handler Signature

Version 3 uses a request handler syntax that more closely matches the Vercel style. In fact, it's the same interface that the Edge runtime uses:

export default async function (request: Request): Promise<Response> {
  console.log(request.url);
  return new Response('...');
}

Migrate from ServerRequest

The more recently supported ServerRequest syntax requires very little changes. The request interface is very similar to the standardized Request type. However, if you were using the .respond() function, you'll want to instead return a Response instance.

-import { ServerRequest } from 'https://deno.land/std@0.106.0/http/server.ts';
-
-export default function (request: ServerRequest) {
+export default function (request: Request) {

   console.log(request.url);

-  request.respond({ body: '...' });
+  return new Response('...');
 }

Migrate from Deno.RequestEvent

The other syntax that was previously supported is Deno.RequestEvent. In this syntax, the Request instance was available on the .request property of the event parameter. Instead you'll want to access the Request instance as the top-level parameter provided to the function. Instead of using the .respondWith() function, you must directly return the Response instance.

-export default function (event: Deno.RequestEvent) {
+export default function (request: Request) {

-  console.log(event.request.url);
+  console.log(request.url);

-  event.respondWith(new Response('...'));
+  return new Response('...');
 }

Legacy Deno Configuration Methods Removed

The deprecated ways of configuring Deno flags (i.e. --unstable) have been removed. Now the only way to configure flags is via the shebang method, as documented in the README.

Migrate from Environment Variables

If you were using the environment variables DENO_UNSTABLE or DENO_TSCONFIG (either via the Vercel project settings dashboard, or vercel.json), those options must now be passed via the shebang of the individual endpoint.

vercel.json:

 {
-  "build": {
-    "env": {
-      "DENO_UNSTABLE": "1"
-    }
-  },
   "functions": {
     "api/**/*.[jt]s": { "runtime": "vercel-deno@3.0.0" }
   }
 }

api/endpoint.ts

+#!/usr/bin/env deno run --unstable

 export default (req: Request) => {
   return new Response('...');
 };

Migrate from config in vercel.json

If you were using the config object in vercel.json to specifiy unstable or tsconfig, those options must now be passed via the shebang of the individual endpoint.

vercel.json:

 {
   "functions": {
     "api/**/*.[jt]s": {
-      "config": {
-        "unstable": 1
-      },
       "runtime": "vercel-deno@3.0.0"
     }
   }
 }

api/endpoint.ts

+#!/usr/bin/env deno run --unstable

 export default (req: Request) => {
   return new Response('...');
 };

Configuration File Paths Relative to cwd

Previously, any file paths referenced by configuration options in an endpoint's shebang were relative to the entrypoint file. This was confusing because it caused a dichotomy between the directory where deno run is invoked vs. the value of the flag in the shebang.

Now those file paths are relative to the cwd that deno run is invoked with. That is, the file paths are relative to the root directory of the Project.

-#!/usr/bin/env deno run --include-files ../data.json
+#!/usr/bin/env deno run --include-files data.json

 export default (req: Request) => {
   const data = Deno.readTextFile('./data.json');
   return new Response(data, {
     headers: { 'content-type': 'application/json' }
   });
 };