Edge Functions netlify:edge include Doesn't Resolve Locally

Support
1

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
2

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?

4

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

1 Like
6

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
7

Thank you! This works!

1 Like
8

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
9

@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"
  }
}
10

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.

12

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.

13

@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.

1 Like
14

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

1 Like
15

The DX of using Typescript+Deno here definitely feels immature (but overall I like the decision to use Deno, and have confidence the development experience will improve).

Like some others here, I struggled to get proper typing from netlify:edge. I ended up rolling my own Context type based on Edge Functions API | Netlify Docs

I’m sure this isn’t exactly right, but it worked for my purposes:

type json = string | number | boolean | null | json[] | { [key: string]: json };

type Context = {
  cookies: {
    get: (name: string) => string | null;
    set: (options: {
      name: string;
      value: string;
      expires?: number;
      domain?: string;
      path?: string;
      sameSite?: "strict" | "lax" | "none";
    }) => Promise<undefined>;
    delete: (options: {
      name: string;
      url?: string;
      path?: string;
    }) => Promise<undefined>;
  };
  geo: {
    city: string;
    country: {
      code: string;
      name: string;
    };
    subdivision: {
      code: string;
      name: string;
    };
  };
  json: () => json;
  log: (values: any[]) => void;
  next: () => Promise<Response>;
  rewrite: (url: URL | string) => URL;
};
16

Hi @zmat. Thanks for the feedback!

You shouldn’t need to roll out your own types, since the netlify:edge identifier should be automatically resolved by our build system. Can you kindly share the error you’re getting, and clarify whether it happens when you’re building your site or just developing locally?

If it’s the latter, have you checked this blog post? It covers the local development flow in detail.

Thanks again, and looking forward to solving this hurdle for you.

1 Like
17

@eduardoboucas Yeah, I read through the blog post, and it was definitely helpful—thanks. I will say that setting up editor/IDE-specific typings feels kind of weird and brittle, and is generally not the sort of thing I’d want to use in a shared code base.

In my case, I am using VS Code. I went through the steps, but ended up first with this error:

Resolved Dependency
Code: netlify:edge
Uncached or missing remote URL:
“netlify: edge”, deno(no-cache)

And then, after I tried to “Cache “netlify:edge” and its dependencies.”, with this error:

Unsupported scheme “netlify” for module
“netlify:edge”. Supported schemes: [ “data” “blob”
“file”. “http”. “https”, 1
Source: Deno (Extension)

While I’m quite familiar with TypeScript, I am not that familiar with Deno. Aren’t Deno imports supposed to resolve to local file paths or remote URLs? This netlify:edge thing feels like a weird way to do that, but maybe I’m missing something.

Regardless, I appreciate the help. Cheers :slight_smile:

19

It looks like some of the files that our build system should be creating are missing. Could you share a list of the steps you’re taking and the commands you’re running?

Thanks!

20

@eduardoboucas Appreciate the offer. All I did was step through the blog post A Deep Dive into Netlify Edge Functions, though. Those were the errors I got after doing the steps outlined there.

For now I’ve elected not to keep using edge functions, mostly because they’re not marked as production-ready yet. Once they are, I’ll definitely revisit. Cheers!

22

Is it correct that it is still not possible to resolve these types locally without using the VS Code extension?

I still get this error when running tsc locally:

Cannot find module 'https://edge.netlify.com/' or its corresponding type declarations.

1 import type { Context } from "https://edge.netlify.com/";
23

There’s no VS Code extension and you should not be using tsc for Edge Functions. They perform their own type-checking. Check this out: Types and Type Declarations | Manual | Deno