fix: toggle DENO_NO_PACKAGE_JSON conditionally

[nyannyacha]

What kind of change does this PR introduce?

Enhancement

Description

Make CLI conditionally toggle DENO_NO_PACKAGE_JSON based on what files are in each function folder.
This only applies when deploying functions locally/Docker and not using the deploy api.

Related supabase/supabase#38402
Towards FUNC-304

[coveralls]

Pull Request Test Coverage Report for Build 19086331832

Details

• 11 of 16 (68.75%) changed or added relevant lines in 2 files are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.01%) to 54.688%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/functions/deploy/deploy.go	4	6	66.67%
internal/functions/deploy/bundle.go	7	10	70.0%

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

Totals
Change from base Build 19065008112:	-0.01%
Covered Lines:	6398
Relevant Lines:	11699

---

💛 - Coveralls

[sweatybridge]

I'm not sure if this is the right fix. Based on their example, the error seems to be caused by health function failing to import package.json on Windows.

Most likely we have a bug in path resolution that's preventing package.json at root repo directory from being volume mounted into the edge runtime container.

[nyannyacha]

@sweatybridge Hello qiao 😄

Well.... I think their reproduction code in that link you mentioned is definitely a bug, but I believe what they reproduce is actually a different bug that seems similar to the issue they're having.

Apparently, the cli is parsing the script directly and passing it a list of the paths that should be bound from the host to pass to Docker.
That link is reproducing a bug that occurred there, but the issue that originally caused that issue was that it was automatically reading the package.json and subtly changing the way the Deno codebase resolves modules.

This is a PR for that.

[sweatybridge]

Is it possible to avoid changing the Bundle method signature? This interface is part of our public package so I'd rather not break it.

If we need to pass in additional args, we can use variadic editor args for backwards compatibility.

[nyannyacha]

Hey @sweatybridge

I also dislike the lengthening iface signature, but I can't think of a suitable way to pass usePackageJson.
Should I define it directly as a field in the dockerBundler struct (and any struct that implements the Bundle interface)?

[nyannyacha]

Could you guide me on how to correctly reference usePackageJson within the Bundle method?
You linked https://github.com/supabase/cli/blob/develop/pkg/config/config.go#L324
But ultimately, to use it within the Bundle method, wouldn't we need to add a variadic argument after the arg list? Is that acceptable?

I just need to be able to reference it within the Bundle, and I'd appreciate it if you could let me know any way to do that. 🥹

[sweatybridge]

But ultimately, to use it within the Bundle method, wouldn't we need to add a variadic argument after the arg list? Is that acceptable?

Yea kinda of. Because adding variadic args is backwards compatible.

Let me think about it a bit more too.