Runtime 2.2.0 is not working about edge-runtime HOT 8 CLOSED

When using version 2.1.4 I actually get the error:

TypeError: Failed to parse URL from null

but this error is coming from the initialCode block and not the edge-runtime itself. Replacing the block with a "Hello World" response fixes the error.

from edge-runtime.

Hello, @oscartbeaumont!

I updated the doc example since it was hard to difference when is or not interacting with a local server, hope it's now more clear https://edge-runtime.vercel.app/getting-started

Also, you don't need to run that code if you just use the edge runtime CLI, or vercel dev, or next dev; they are wrapping this code for you 🙂

from edge-runtime.

I have resorted to using the Edge Runtime code directly because as far as I am aware a custom framework can't tell vercel dev about the edge functions it creates. I really really want to move back to Vercel CLI so if you've got any pointers or know where I should open an issue, any help would be appreciated!

For some more context, I am building a mini-framework based around SolidJS's renderToStream. I made a little CLI that can compile the user's code into an edge function and I am currently outputting it in the Vercel Build Output API v3 format. This works perfectly when deployed to Vercel but I am unable to get a development setup working with it.

The primary challenge is that the edge function needs to be created by my code because I use a custom Vite plugin to inject an SSR manifest (So my code can know the names of the client bundles Eg. index-687ghg2.js).

Using vercel dev just runs Vite's dev server which serves the assets but doesn't expose the edge functions as Vercel's CLI has no way of knowing about the edge functions except for maybe checking the .vercel/output/functions directory which it unsurprisingly doesn't seem to do.

I also tried creating a custom runtime (following this) but vercel dev throws the following error when using it because I am returning an EdgeFunction instead of a Lambda.

Error: The result of "builder.build()" must be a `Lambda`

Interestingly vercel build work works fine with this setup so this seems to be a limitation in the dev server only. Do you know much able the Vercel CLI and if this would be a bug or is the intended design? Fixing this would likely be the best solution to my problem!

To workaround this I am using the edge-runtime package directly so that I can have it hot reload whenever the Vite devserver emits a change event but it's not a very good solution as it requires bundling the edge-handler-template.js and as you have implied it's not designed to be a high-level API. I am also concerned that this setup could cause drift between my dev setup and Vercel's prod environment over time as I also miss out on Vercel's request routing, headers, rewrite, etc that the CLI is able to handle.

I have created a super minimal reproduction of my setup as code can help to illustrate what I'm saying. If you had any ideas to help they would be greatly appreciated and I love the work you are all doing on the Edge runtime!

from edge-runtime.

You are correct that vercel dev does not work with the Build Output API. Instead, it is expected that the frontend framework being used (so your mini-framework in your case) offers its own local dev server command (i.e. next dev for Next.js), and vercel dev simply proxies to that local server as specified the the Dev Command in the Project Settings.

So in your case you would want to write a local dev server that utilizes this edge-runtime package to provide the proper execution environment, and configure the Dev Command to invoke that server when vc dev is run.

We do have plans for something like a vercel start command. That would operate on the Build Output API contents, and would be targeted towards framework authors to verify that their Build Output API implementation works correctly before deploying to Vercel. But it wouldn't do "dev" stuff like file watching and re-processing build outputs at runtime, so would not be meant for an end-user to use during development.

from edge-runtime.

Thanks, both of you for helping!

To me, this feels like such a loss because from what I can see you have most of the runtime APIs in place to support this given a builder can just return a Lambda and it works in dev mode with the Vercel CLI acting as a file watcher. From a framework author's perspective, it means they have to not just need to implement the edge runtime into their CLI but they also need to implement their own routing system to set HTTP headers, redirect, and rewrites instead of just being able to use them from the vercel.json. I understand a lot of frameworks probably want to do this themselves and that's fair but for something which is relatively simple like I am doing, it means going from a ~100 line Vercel runtime to having a whole CLI that is probably going to end up at least triple that size.

from edge-runtime.

@Kikobeats I am looking at the updated examples and they still show the usage of both initialCode in new EdgeRuntime({ initialCode }) and also .dispatchFetch which are both shown as invalid by Typescript in version 2.2.0 of the edge-runtime. Do you know what I should be using instead?

from edge-runtime.

Moving to version 2.3.0-beta.2 seems to fix all the issues I was having with 2.2.0.

from edge-runtime.

Just came cross this issue since nitro tests for vercel-edge were broken. Sharing if this might help: https://github.com/unjs/nitro/blob/main/test/presets/vercel-edge.test.ts

from edge-runtime.