Closed evelant closed 5 months ago
@evelant we will look into providing customization options for the project structure.
Also, would you be interested in jumping on a quick call with me to summarize your monorepo setup and how you use edge functions? It will help us to design a better solution to handle different use cases.
@laktek Sure I could chat tomorrow, just let me know when
@evelant are you still having this issue? This setup seems to be working as expected for me.
I have a mono repo with supabase
, a react-app
(typescript vite), and a scripts
(typescript node) folder for some.
In vscode I can open the root project and edit the supabase/functions
app OR the react-app
. However, once I start editing the react-app, the deno files for some reason start getting picked up by the ts LSP instead of the deno LSP.
I think there's probably some way to configure vscode workspaces...
CLI now has an option to setup vscode workspace for edge functions when running supabase init. Does it work for you?
@sweatybridge Unfortunately not, I already tried the vscode workspace trick. It seems there are multiple bugs in vscode_deno which unfortunately don't seem to be getting any attention from the Deno team. They've seen no movement for at least the last 3 months. https://github.com/denoland/vscode_deno/issues/878 https://github.com/denoland/vscode_deno/issues/967 https://github.com/denoland/vscode_deno/issues/873 https://github.com/denoland/vscode_deno/issues/488
Has the Supabase team considered supporting something other than Deno for the edge runtime? I realize you're pretty invested in it given the use of Deno deploy and all of the custom tooling you've had to build to make it work, but Deno is just so incredibly painful to work with.
I've had to code edge functions exclusively without type checking. Import maps break all the time and must be manually kept in sync with package.json versions used in shared code. I get random 502 errors on clients with no logs indicating a problem. I get random slow response times. Packages imported from esm.sh working at all is a crapshoot. The editor support is of abysmal quality (this issue)... and so on.
I've wasted so much valuable time fighting with Deno for what should be a simple use case. I have some code in a shared package in a standard pnpm monorepo that uses some libraries from npm. I need to use that code in fairly simple edge fns. Doing that is incredibly much harder than it should be.
Bun would be a fantastic alternative. It just works with modern code and ecosystem and has batteries included tooling for seemingly a lot of the stuff you've had to hack into working with Deno (like bundling local shared code).
I would also like to voice my frustrations in regard to using edge functions in a monorepo with any sort of complexity. I'd like to import code I have in packages/*
but it's nearly impossible. Deno was a mistake. Forced to use Vercel instead.
I really agree. Edge functions in Deno in my repo has been the single biggest pain with using Supabase. I really wish we could just have node edge functions, it would make the project so much simpler to maintain
I would also like to voice my frustrations in regard to using edge functions in a monorepo with any sort of complexity. I'd like to import code I have in
packages/*
but it's nearly impossible. Deno was a mistake. Forced to use Vercel instead.
This is the only pain in my stomach as of now, otherwise vscode related issues are almost ok now. Any serious application must have a proper backend (like nest etc.) in addition to edge functions and monorepo is a reality nowadays. Currently, i am writing code inside supabase/functions and import them to nest modules when i need them but this is not optimal. If only supabase let importing/copying other packages from a parent folder, this could be solved as well.
If only supabase let importing/copying other packages from a parent folder, this could be solved as well.
We have addressed a few issues in the last week. I believe importing packages from parent folder is supported properly via import map now. Could you give the latest CLI v1.176.4 a try and let me know? For eg.
supabase/functions/import_map.json
with the following contents:{
"imports": {
"common": "../../common/"
},
}
supabase/functions/hello/index.ts
as followsimport { SomeType } from "common/types.ts";
.vscode/settings.json
{
"deno.enablePaths": ["supabase/functions"],
"deno.importMap": "supabase/functions/import_map.json",
"deno.lint": true
}
@sweatybridge it doesn't work for me. It doesn't deploy with latest deno and supabase versions. I am also on windows 11.
The import map has "@mylib/shared/": "./_global/src/"
and my function has import { ApplicationError } from "@mylib/shared/types/errors.ts";
. This way deno-lint and typescript see the code valid, but supabase deploy throws the following error:
Error: failed to load 'file:///home/deno/_global/src/types/errors.ts': Module not found "file:///home/deno/_global/src/types/errors.ts"
I don't know why it is trying to fetch it from "/home/deno". The same code works when i import using import { ApplicationError } from "../_global/src/types/errors.ts";
The directory structure is as follows:
supabase/functions/
import_map.json
myfunction/
index.ts
_global/
src/
types/
errors.ts
EDIT:
It works when i add "functions" to the path like ""@mylib/shared/": "./functions/_global/src/"
. However, this time deno lint fails to detect the import in vscode.
However for parent folders (outside supabase folder) it doesnt work either way, the moment i use "../" in the path it fails to deploy.
It works when i add "functions" to the path like ""@mylib/shared/": "./functions/_global/src/". However, this time deno lint fails to detect the import in vscode.
@ardabeyazoglu Have you updated CLI to latest version v1.176.4? We specifically fixed this issue with import map.
@sweatybridge Yes, it is 1.176.4.
@ardabeyazoglu could you show me the contents of all the json files in supabase/.temp/import_maps
?
@sweatybridge there is no such file. This is the contents of the directory.
-a--- 12/06/2024 12:07 8 cli-latest -a--- 04/06/2024 09:15 8 gotrue-version -a--- 04/06/2024 09:15 109 pooler-url -a--- 04/06/2024 09:15 8 postgres-version -a--- 04/06/2024 09:15 20 project-ref -a--- 04/06/2024 09:15 7 rest-version -a--- 04/06/2024 09:15 6 storage-version
Thanks for your help, I managed to reproduce the issue and release a fix. Could you try npx supabase@beta functions serve / deploy
?
@sweatybridge I can confirm it works with supabase cli 1.176.10. Having import_map inside functions folder, and using relative path like "../../parent-lib/" works when deploying and running the function as well as linting in vscode. Well done, thanks!
This issue is far from closed.
@sweatybridge For me it only works when the file I try to import is at least in the project root directory (using npx supabase@beta functions serve
)
For for example:
/path/to/
some_other_file.ts
my-project/
some_file.ts
supabase/
functions/
import_map.json
import_map.json
{
"some_file": "../../some_file.ts" <---- works
"some_other_file": "../../../some_other_filter.ts" <---- works not
}
I'm also able to import some_file
via an absolute path while some_other_file
doesn't seem work.
I would be happy about any advice 🙂
I started working on a code base using supabase and I'm quite surprised that I'm not able to execute code in edge functions from outside the /supabase/functions
directory. There are some types and implementations I want to use both in front and back end and beyond that I don't want to couple my logic to supabase.
It seems like the only option is to publish the shared logic to npm, which unnecessarily complex for the use case.
Very possible that I'm not seeing an obvious solution here, so if anyone has found out how to reference code outside the /supabase/functions
folder, please let me know :) <3
@sweatybridge do you refer to a directory outside of /supabase
here?
{ "imports": { "common": "../../common/" }, }
If so, that doesn't work for me, as soon as it's outside /supabse/functions
, I get a
serving the request with /Users/my-project-folder/supabase/functions/hello-world
failed to load 'file:///Users/my-project-folder/supabase/hello.ts': Module not found "file:///Users/my-project-folder/supabase/hello.ts".
An error has occured
InvalidWorkerCreation: worker boot error failed to load 'file:///Users/my-project-folder/supabase/hello.ts': Module not found "file:///Users/my-project-folder/supabase/hello.ts".
at async UserWorker.create (ext:sb_user_workers/user_workers.js:144:15)
at async Object.handler (file:///root/index.ts:147:22)
at async respond (ext:sb_core_main_js/js/http.js:163:14) {
name: "InvalidWorkerCreation"
I'm using supabase v1.187.10
I've been having trouble with this as well. I was able to do the initial setup for the NextJS Subscription Payments starter However, once I needed to add a Supabase Edge Function I'm running into several Deno-related issues in VS Code.
I have the same issue as @ccarstens. I get InvalidWorkerCreation: worker boot error failed to load whenever i try to import things from outside of the supabase/functions/ directory
Describe the bug
This may not be actionable by the Supabase team since it may be a bug in Deno but I at least wanted to bring it up here for visibility. Since Supabase by default puts the edge functions project in a sub-directory this breaks the ability to edit Deno code with Deno LSP if there is a root package.json.
For more detail see the issue filed at vscode_deno: https://github.com/denoland/vscode_deno/issues/878
To Reproduce Steps to reproduce the behavior:
Expected behavior Default project structure should try to work around Deno's quirks. Or more ideally allow building edge functions with a less problematic runtime such as Bun.
Screenshots
Desktop (please complete the following information):
Additional context