Edge Functions netlify:edge include Doesn't Resolve Locally

Hello!

In the Edge Functions Example here: JSON Response | Edge Functions on Netlify

Which looks like this:

import type { Context } from "netlify:edge";

export default async (request: Request, context: Context) => {
  return context.json({ hello: "world" });
};

The import from “netlify:edge” doesn’t resolve locally. It does work with the Netlify CLI locally.

But since one of the points of Typescript (and specifically importing that type into the file) is to enable your IDE to do auto-complete and validation, the fact that we don’t get even the type definition locally is not ideal.

Is there perhaps a way to get at least the type definitions locally?

Also, the fact that “netlify:edge” doesn’t resolve drives WebStorm’s Deno support crazy, and it lists every file that imports from it as having a missing import. :slight_smile: I opened an issue about that with JetBrains, but whether we get the code locally or not, I do believe we need some way to access the type definitions. :thinking:

Thank you!

1 Like

Hey there, @timlwhite

Thanks so much for bringing this up. We can bring this to our team that works on Edge Functions, as I recognize that something like this could improve your experience.

In the interim, can you confirm if you are blocked or encountering obstacles with this? I hear that you say “it is not ideal”, but are you still able to proceed with building?

Thank you! Confirmed that I am not currently blocked. :+1:t2:

1 Like

Hey @timlwhite,

Thank you for trying out Edge Functions and that actionable feedback. We see how this is a problem.

At the moment, we’ve already integrated an automated workflow for VS Code users to get these type definitions, and we we develop this product more, we’d be looking into options for expanding this to other IDEs.

For now, we do have a workaround for you. Instead of netlify:edge, you could use https://edge-bootstrap.netlify.app/v1/index.ts to get those type definitions. Note that, this URL is subject to change and we mostly won’t be notifying anyone using this URL manually. So if you choose to use it, and it stops working, you might have to ask us again about the latest URL or follow the docs (if we post it there).

1 Like

Thank you! This works!

1 Like

Hi @hrishikesh: Thanks for sharing that information. Without it, I wouldn’t have been able to get type-checking working in VS Code using the Deno language server. I’m sure I’m not the only one who’s using this approach with edge functions, and I’m wondering: what’s preventing the team from publishing the types, as they evolve, at versioned and immutable URLs?

(Also, please add that types link in the docs: I had to search quite a bit to find this post and almost gave up entirely along the way!)

1 Like

@jsejcksn I am assuming once this is out of “Experimental” mode and production ready, they will release the types in a proper manner compliant with rest of the Deno ecosystem i.e. versioned, immutable, etc

FWIW, I noticed when I ran netlify dev (after upgrading to latest netlify-cli) in a project that had an edge function, it scaffolded an deno.importMap like this:

{
  "imports": {
    "netlify:edge": "https://edge-bootstrap.netlify.app/v1/index.ts"
  }
}

Interesting, I created an import_map like that manually in my project after getting that URL from this thread. That would definitely help if they do that automatically.

At the moment, when using Netlify CLI with VS Code, this resolution happens automatically, or at least it’s expected to happen. I’m getting mixed feedback from the comments, is it or is it not working so?

For all other IDEs, you might have to import using the mentioned URL. As far releasing a versioned URL, that’s actually an ongoing discussion for when we release Edge Functions as GA. We created the alias to remove the burden of managing versions from the user, but we also considering keeping that option in sync with the Deno ecosystem.

@hrishikesh The Netlify CLI is not a required part of the workflow (and I’m not using it in the edge functions project that I mentioned). I am only using git, deno, VS Code, and the VS Code Deno extension. "netlify:edge" is not a valid remote module specifier, nor is it a valid npm package, so without an import map in Deno or customizing TypeScript’s path mapping in Node, using that specifier always results in a TypeScript compilation error.

I can cache modules and other static source files from remote URLs (Deno) and npm (Node), but running any other processes outside of a sandbox is not possible here (and shouldn’t be required just to type check).

The core point of my message is that there is no officially documented route for type acquisition apart from installing the Netlify CLI (which I cannot do for this project repository), and that’s what I’m hoping will be improved in this development story.

Thanks for the feedback @jsejcksn. That totally makes sense and we’ve shared it with the team.

1 Like