How to improve Deno DX for Supabase Edge Functions?

[joshxyzhimself]

Sorry for the language, but it's a lot of developer experience friction, really.

When I use cloud functions from other cloud providers I can usually get up and running in 5 minutes and at the same time my VSCode won't be screaming errors because my functions are simply written in JavaScript or TypeScript.

Deno is a different beast, it's a separate runtime with a separate linter and separate development environment configurations. A total pain in the ass to deal with.

Look at it, TypeScript IntelliSense doesn't even work out of the box on a project that uses ESLint.

I've tried installing deno, installing the Deno VSCode extension, creating a deno.config file, configuring the Deno VSCode extension's deno.config and deno.path properties. It's just a mess.

[cohlar]

Had the same issue, and made it work as follows:

• installed the denoland.vscode-deno extension
• added "deno.enablePaths": ["supabase/functions"] to .vscode/settings.json
• added "include": ["**/*.ts"] to tsconfig.json

Hope it helps.

[subvertallchris]

This did the trick for me. I also had to tell eslint to ignore it by adding this to my .eslintrc.json:

"ignorePatterns": ["supabase/functions/**/*.ts"]

[inian]

Here is an end to end example of configuring VSCode to work with Deno - https://youtu.be/rzglqRdZUQE?t=144 and end to end quickstart here - https://supabase.com/docs/guides/functions/quickstart

If you are using Edge functions along with other code, checkout how to configure Deno with VSCode workspaces here - https://www.youtube.com/watch?v=lFhU3L8VoSQ

[ArmanAryanpour]

The steps are pretty simple actually:

Install Deno CLI from this page

Make sure deno is in your PATH variables on windows. To test this, in a new terminal, type "deno" and if it says command not found you've got an issue. Google on how to fix this.

Install Deno Vscode Extension from this page

Create a .vscode folder and a settings.json file in the root of your project.

And put the following inside of it:

{
    "deno.enablePaths": ["supabase/functions"]
}

For example, my directory structure looks like this:

• .vscode
• supabase
  • functions
    • hello-world
      • index.ts

In your functions, when adding new libraries, you might notice an error:

As it mentions, it is because the library is not cached. After caching it:

You can see that all the vscode goodies start to work.

I hope these help.

[bombillazo]

Using Deno for Edge functions has been the worst part of our DX with Supabase so far. The docs don't go much beyond a simple, 1 file function index.ts file with a few external deps because as soon as you get into trying to import local files, deps from multiple CDNs, more custom import_map.json setups, things get very hard to scale, run for development and deploy.

Even testing locally with serve is a hassle and what runs with the native deno cli commands are not guaranteed to work properly, neither locally with Supabase nor once deployed. Most of the Supabase issues, discord, and discussions are related to deno edge functions. Even using the Supabase client inside edge functions with https://deno.land/x/[email protected] loses TypeScript support...

I wish they would've opted for the industry standard of Node and later added Deno for those who want to be at the cutting edge.

[ibsusu]

seriously. everything else about supabase is super smooth. I hate deno and edge functions so much it has literally been the only reason I've considered just rolling my own api server. Just why???

[laktek]

Even testing locally with serve is a hassle and what runs with the native deno cli commands are not guaranteed to work properly, neither locally with Supabase nor once deployed.

This is because the runtime used by Deno Deploy (which Supabase currently uses to host Edge Functions) differs from the Deno CLI. You can check the APIs supported by it here https://deno.com/deploy/docs/runtime-api

We try to mimic the Deno Deploy's API when you are testing locally with serve. That's why you will find things that works with Deno CLI doesn't work with serve. Also, we recently open-sourced Edge Runtime which we use under the hood for serve. It's still beta and active development - but it should give you parity with Deno Deploy environment.

@bombillazo @ibsusu Thanks for reporting the issues you experienced. We are trying our best to resolve them as soon as we can.

[ibsusu]

I'm sorry for being so negative. Really, everything else about supabase has been enjoyable - great even. I know you guys are trying.

[bombillazo]

I agree, it's not a diss on Supabase, I know the team is working hard to improve the product, but it is evident the edge-function piece is not on par with the rest of the product and is not as easy to work with.

[thorwebdev]

Thanks for the feedback, we appreciate you taking the time, and luckily some things we can action quite quickly.

1. https://deno.land/x/[email protected] is not owned by us and should not be used. I'll reach out to the Deno team to get that taken down.
2. The official guidance is to use esm.sh for the time being: https://supabase.com/docs/reference/javascript/installing#use-at-runtime-in-deno , I'll make sure to make this clearer in the Edge Functions docs.

[ArmanAryanpour]

I faced similar issues. I ended up having 2 import files, one for local development and one for production. Supabase will automatically pick import_map.json from functions folder and we manually set local_import_map.json in the vscode settings.

Basically your local import can use npm: packages and will be perfectly typed.

But on prod, supabase needs pure esm files from services like esm.sh.

Not the best DX.

Haven't been able how to have pretty absolute urls like @utils as those do not work when deployed to supabase but work in deno locally.

I can't believe it would be too difficult to sync secrets across big providers like GCP and AWS and allow the flows supported by those cloud functions with the CLI and then allow any language to be used (specially since there are many client libraries making this even smoother).

[ArmanAryanpour]

@laktek I have tried but with esm.sh packages locally, you don't get typescript or autocomplete etc. Maybe my project setup is wrong? But specially for things like Stripe, you have to pass the no-type param when using esm.sh which will ... get you no types 😆

The only smooth solution I found for this was 2 import_maps, one for locally with deno and one for prod with esm.sh.

[laktek]

Usually, esm.sh should give you types unless you pass ?no-dts (or ?no-check) param when importing. Do you have examples other than Stripe where this happens?

[bombillazo]

@ArmanAryanpour , we got it to be workable locally and deployable to supabase with the same import_map file. Some points:

• import_map.json needs to be inside the supabase/functions directory. The serve command does not respect properly the --import-map flag and we found it easier to simply place it there.
• You must use supabase serve only, do not call functions individually (e.g. supabase serve my-function) as this command does not respect the import-map file correctly to import the external/local dependencies.
• In VS Code, we enable deno in our workspace settings (there is a video in supabase on how to) Our settings are:

  "deno.config": "./deno.jsonc",
  "deno.enablePaths": ["./supabase"],
  

• Make sure to install the Deno vscode extension. The deno.jsonc is a file at the root of the project containing the path to our import map and other general deno settings so that we can run and inspect deno code.

  {
    "compilerOptions": {
      "allowJs": true
    },
    "importMap": "./supabase/functions/import_map.json",
    "unstable": true
  }

• Use the VS Code command palette to Deno: Restart language server to troubleshoot the extension getting stuck/caching incorrectly
• Try other CDN services (denoland, skypack, unpkg), we've got a mix of different CDNs because not all packages are built equally, and it is a true effort of trial and error to test importing different ones until they work.

[ArmanAryanpour]

Usually, esm.sh should give you types unless you pass ?no-dts (or ?no-check) param when importing. Do you have examples other than Stripe where this happens?

I believe the reason was solely stripe as that's the core of our use case and deno edge functions is where it would be implemented.

But I also had a lot of trouble with importing relative folders. For example a simple: @Util mapped to a folder outside of where the deno functions were would deployment but work fine during development.

[ArmanAryanpour]

@ArmanAryanpour , we got it to be workable locally and deployable to supabase with the same import_map file. Some points:

• import_map.json needs to be inside the supabase/functions directory. The serve command does not respect properly the --import-map flag and we found it easier to simply place it there.
• You must use supabase serve only, do not call functions individually (e.g. supabase serve my-function) as this command does not respect the import-map file correctly to import the external/local dependencies.
• In VS Code, we enable deno in our workspace settings (there is a video in supabase on how to) Our settings are:

  "deno.config": "./deno.jsonc",
  "deno.enablePaths": ["./supabase"],
  

• Make sure to install the Deno vscode extension. The deno.jsonc is a file at the root of the project containing the path to our import map and other general deno settings so that we can run and inspect deno code.

  {
    "compilerOptions": {
      "allowJs": true
    },
    "importMap": "./supabase/functions/import_map.json",
    "unstable": true
  }

• Use the VS Code command palette to Deno: Restart language server to troubleshoot the extension getting stuck/caching incorrectly
• Try other CDN services (denoland, skypack, unpkg), we've got a mix of different CDNs because not all packages are built equally, and it is a true effort of trial and error to test importing different ones until they work.

I tried something similar and got it working but I must admit, we had to part ways with it.

It seems that Deno is not the best choice for monorepo's and it was becoming too much to handle to share between packages, specially during development. Just decided to use vercel instead to get the same edge latency just with the good old node run time. Hopefully, one day I can either code in node on supabase or deno becomes enjoyable to use. Supabase is great otherwise, and thanks to all the maintainers ❤️