fix(edge-functions): add warning for edge-functions configuration

[avallete]

What kind of change does this PR introduce?

Closes: #2983

What is the new behavior?

Add a warning preventing about deprecated global deps use, and import_map usage:
Here 3 functions, hello-world, hello-word2, hello-word3 only one of them declare a valid deno.jsonc deps, here the result:

Additional context

[coveralls]

Pull Request Test Coverage Report for Build 12667649354

Details

• 22 of 29 (75.86%) changed or added relevant lines in 2 files are covered.
• 6 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 59.612%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/functions/new/new.go	12	15	80.0%
internal/functions/deploy/deploy.go	10	14	71.43%

Files with Coverage Reduction	New Missed Lines	%
internal/functions/new/new.go	1	88.57%
internal/gen/keys/keys.go	5	12.9%

Totals
Change from base Build 12664619273:	-0.01%
Covered Lines:	7721
Relevant Lines:	12952

---

💛 - Coveralls

[avallete]

This would fix the issue, but I wonder if we should rather move toward a more "isolation" approach with something like this in the docs for the edge functions:

**Note:** Each Edge Function should be treated as an independent project with its own `deno.json` or `import_map.json` file. Avoid placing shared configurations at the root of the `functions` directory, as this can lead to conflicts. This ensures functions remain self-contained and portable.

Could also mention the .npmrc as mentioned here: #2979

I'm happy to close the PR and go toward this approach if we choose it instead.

[sweatybridge]

Two suggestions.

1. We should handle both .json and .jsonc like in per function config parsing.
2. I agree we want to encourage isolation for deployed functions. The default import map was only added for convenience for local dev and serving.

I'd prefer updating the docs to mention the suggested path for deno.json for deployment so it's less confusing for new users.

[avallete]

Two suggestions.

1. We should handle both .json and .jsonc like in per function config parsing.
2. I agree we want to encourage isolation for deployed functions. The default import map was only added for convenience for local dev and serving.

I'd prefer updating the docs to mention the suggested path for deno.json for deployment so it's less confusing for new users.

Good spot for the jsonc.

I think the issue with the "convenience shortcut" is that it create the expectation that things will work the same way between all the ways you can define your deps. And even if we mention things in the docs, it's not the best for discovery.

Here is what I would like to propose:

1. Support the "global deno.json/deno.jsonc" for consistency with the import_map.json shortcut behavior.
2. Mention in the docs that each function should be isolated, etc...
3. Add a warning for every function that use the fallback on the cli side. So it stand out for the user that this is not a suitable ways to do things and should only be used for development, redirect to the docs (prepare to remove this completely for the next major as a breaking change thing ? We could provide a shellscript'ish way to easily do the migration by copying the global into the subfolders)
4. Maybe a good way to nudge the users in the right direction is that when we do functions new, on top of the index.ts also create a deno.json and .npmrc files in the created folders ?

I've reworked things toward this and refactored a bit how we handle the "default path", and created a PR for the documentation here: supabase/supabase#31264

WDYT ? @sweatybridge @jgoux

[jgoux]

+1 with @sweatybridge on only updating the docs and explaining that one deno.json(c) per function is the best practice, and maybe add a deprecated mention on the import_map.json file in functions.

dismissing to prefer docs update #2984 (comment)

[avallete]

Changed the PR to remove the "global fallback handling" and keep focus over:

1. Providing warning and feedbacks if the function isn't configured the recommended way.
2. Add empty deno.jsonc and .npmrc template when running function new to setup user for success.