bug: set process.env as own property

[joelpramos]

See: denoland/deno#27891
and: https://github.com/orgs/supabase/discussions/33244

I understand we're currently pinned on a custom edge runtime, but can we add the process.env, similar to how it was done in Deno? I am facing the issue with googleapis. It's unclear to me whether I had this issue a while back as in my local I was using Deno 2.2 for local dev until pinning it.

Unfortunately I can't downgrade googleapis as low as necessary to avoid the gcp-metadata newer version as listed in the supabase discussion as it breaks compatibility with the actual Google APIs I am trying to use.

[kallebysantos]

Hey @joelpramos 💚
I believe it should be already working, since #485.

May you share a replication example?

[joelpramos]

seems like this fix was already cherry picked a while back into the runtime... super weird. let me try to dig further.

[kallebysantos]

@joelpramos Please feel free to reopen it if you think the issue is not solved.

[joelpramos]

@kallebysantos yeah it's not an issue - it's HOW I run my unit tests. I have a battery of tests that had always been working but recently I've been trying to pin Deno versions and as I pin into Deno 2.1.4 the fix is obviously not there but it's also not the same runtime as this edge runtime. I guess previously I was on Deno 2.2 (and then at some point hit some other issue which made me learn about your custom runtime).

Is there any documented mechanism to run things like deno test locally/in a pipeline but with the Supabase edge-runtime? I'm looking for exactly reproducing behaviours...

[kallebysantos]

Hey @joelpramos

any documented mechanism to run things like deno test locally/in

Please take a look into my draft docs where I do explain how to use the edge-runtime cli to run JS code.
There's no test command but you can use Deno assert lib to throw on error.

[joelpramos]

@kallebysantos appreciate your docs. Helpful explanation and at the very least I was able to run my functions using it etc. which gives me some control.

That said, having a mechanism to run tests is an absolute basic need.

I have a lot of Deno.test() files and quite some that also use testcontainers to spin up supabase locally (for e2e integrated tests in pipelines - can easily be solved with some docker in docker hacks). Not running tests is not really an option :)

I would think the tests runner is packaged within the version you adopted of Deno. Is this "just" a matter of exposing the test cli command?

[joelpramos]

@kallebysantos I took a first take at introducing a supabase test cli in the edge-runtime: https://github.com/joelpramos/edge-runtime/pull/1/changes

Not perfect but it worked to execute tests within edge-runtime container in some of my early tests locally. Haven't yet made the 'docker in docker' work, which you can see my plan was just building an extra Docker layer (so we are not over bloating the actual edge-runtime). Can you take a look and wondering whether you'd be able to help with the final push on it?

if this makes sense to you we can maybe open a new issue to implement this and then later the command can be added to the cli (supabase test .. with the same flags as deno test for familiarity)