event.platform is undefined when deploying on Vercel

[alexbjorlig]

Describe the bug

When I deploy my project on Vercel, this line gives undefined:

export const GET: RequestHandler = async (event) => {


    console.log('is platform here?', event.platform); // Why is event.platform undefined here?
    return json({ message: 'GET request to the homepage', platformDefined: !!event.platform });
}

Do I need to do something different?

My svelte.config.js looks like this:

import adapter from '@sveltejs/adapter-vercel';

import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// Consult https://kit.svelte.dev/docs/integrations#preprocessors
	// for more information about preprocessors
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter({})
	}
};

export default config;

I also tried adding a console.log in src/hooks.server.ts like this:

import type { Handle } from '@sveltejs/kit';

export const handle: Handle = async ({ event, resolve }) => {

    console.log('hooks-server:', {platform: event.platform});
	const response = await resolve(event);
	return response;
};

But this was also undefined?

Reproduction

repo to clone is here.

Deployed vercel project is here.

Logs

is platform here? undefined

### System Info

```Shell
System:
    OS: macOS 14.5
    CPU: (10) arm64 Apple M1 Max
    Memory: 444.77 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
    npm: 10.8.1 - ~/.nvm/versions/node/v20.12.2/bin/npm
    pnpm: 8.15.4 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 125.0.6422.142
    Safari: 17.5
  npmPackages:
    @sveltejs/adapter-vercel: ^5.3.1 => 5.3.1 
    @sveltejs/kit: ^2.5.10 => 2.5.10 
    @sveltejs/vite-plugin-svelte: ^3.0.0 => 3.1.1 
    svelte: ^4.2.7 => 4.2.18 
    vite: ^5.0.3 => 5.2.13

Severity

annoyance

Additional Information

[dummdidumm]

What are you using platform for? It's only defined for edge functions, because its only member, context, is only available within edge functions (settable through the runtime adapter option). The only member of context is waitUntil, which you can now import directly in both edge and serverless functions: https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions

@Rich-Harris should we "shim" this for serverless, by passing along a "fake" context on which we provide the waitUntil method? I tend towards "no, use the package Vercel provides directly". If you're using platform you're already provider-specific.

[alexbjorlig]

What are you using platform for? It's only defined for edge functions, because its only member, context, is only available within edge functions. The only member of context is waitUntil, which you can now import directly in both edge and serverless functions: https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions

@Rich-Harris should we "shim" this for serverless, by passing along a "fake" context on which we provide the waitUntil method? I tend towards "no, use the package Vercel provides directly". If you're using platform you're already provider-specific.

It was exactly waitUntil. Ok, so the recommended approach is to import it from here import { waitUntil } from '@vercel/functions'?

I'm not sure why, but I was under the impression that such thing should live on the "platform", but importing from @vercel/functions would also be ok.

[Rich-Harris]

I tend towards "no, use the package Vercel provides directly"

I lean the same way - it would just add code to people's bundles if they weren't using it. For consistency it might even be better to remove it from edge functions? (deprecate with warning first, obvs)

[dummdidumm]

Ok, so the recommended approach is to import it from here import { waitUntil } from '@vercel/functions'?

Exactly

I'm not sure why, but I was under the impression that such thing should live on the "platform"

platform is more for things that are per-request and coming from the underlying platform. But yeah it's not very strict what's coming from where. In this case, since Vercel provides it, it's better to use the package directly.

For consistency it might even be better to remove it from edge functions? (deprecate with warning first, obvs)

Makes sense

[eltigerchino]

Isn't it already populated here?

kit/packages/adapter-vercel/files/edge.js

Lines 13 to 24 in f67898d

	export default async (request, context) => {
	await initialized;
	return server.respond(request, {
	getClientAddress() {
	return /** @type {string} */ (request.headers.get('x-forwarded-for'));
	},
	platform: {
	context
	}
	});
	};

The ambient type for it exists too although it's not correctly included when importing the adapter at the moment.

kit/packages/adapter-vercel/ambient.d.ts

Lines 1 to 12 in f67898d

	import { RequestContext } from './index.js';
	declare global {
	namespace App {
	export interface Platform {
	/**
	* `context` is only available in Edge Functions
	*/
	context?: RequestContext;
	}
	}
	}

Or am I mistaken and thinking of something entirely different?

[dummdidumm]

It's there, but it's only set for edge functions, not serverless functions, hence the confusion and thought to remove the context for edge, since it only contains waitUntil. Argument against it is that at some point in the future there might be other things on the context object and we would go adding it back in again - which makes me think we just leave everything as is and close this issue.