Use deno.json configuration file in Edge Functions

[jgoux]

Each Edge Function can now have its own deno.json or deno.jsonc file to manage dependencies. You will need to deploy your functions using Supabase CLI version v1.215.0 or above to make use of this feature.

How to use deno.json

Create a deno.json in your function's folder:

// supabase/functions/function-name/deno.json
{
  "imports": {
    "lodash": "https://cdn.skypack.dev/lodash"
  }
}

You can now use aliased imports in your source code:

// supabase/functions/function-name/index.ts
import lodash from 'lodash'

To test your function locally, run supabase functions serve. When you're ready, you can deploy it to hosted platform by running supabase functions deploy function-name

For more details, check the guide: https://supabase.com/docs/guides/functions/import-maps#using-denojson-recommended

[elyobo]

What are the downsides to not using per function import maps / deno.json files? I am currently deliberately not doing this because I share a lot of code across my functions and want to ensure that each function is using the same version of the common dependencies and using a single import map ensures consistency in a way that multiple files cannot.

My edge functions are conceptually part of one application and should have a common set of dependency versions and the recommended approach (per function deno.json) seems actively harmful.

As well as having a single import map, further up (not deployed), I have a single deno.json that I use for deno fmt, deno lint, deno test, and deno check - again, treating all of the functions as part of a single consistent application which they logically are even if they're isolated at a lower level.

[jgoux]

The right way to deal with shared dependencies will be to support Deno workspaces. It's something we want to support in the near future! 👍

[elyobo]

Sounds interesting, thanks! I'll keep an eye on it (and keep doing what I'm doing in the interim).