Update CMD to serve instead of run; remove deps.ts in favor of deno.json

[kimdcottrell]

This fixes this issue:

#424

You can fix that issue as well by keeping the CMD as is, but you have to alter the main.ts to be:

Deno.serve(
    { port: 1993, hostname: "0.0.0.0" }, 
    (_req) => new Response("Hello, world")
);

I went with deno serve since you can keep all the hostname and port configs in the Dockerfile and reduce repetition.

deps.ts was removed in favor of demo.json as it, or package.json , seems to be the path forward in Deno 2.

[CLAassistant]

All committers have signed the CLA.

[lucacasonato]

This is not preferable. With deno cache on like 62, we are going to install only dependencies that are actually used. Here all deps are installed, even if they are unused. We should wait for denoland/deno#27229

[kimdcottrell]

I agree. The dependency install and the caching of it should be sorted first.

The main reason I made this PR was to overcome an issue around the CMD and how the webserver was running, which would throw an error thanks to the approach it was using.

The deps.ts -> deno.json blurb got caught up in this since that also appears to be a remnant from Deno 1.

I'll try to keep an eye on your PR, and once it's merged, I'll alter this one to reflect your approach.

[fry69]

Since the mentioned denoland/deno#27229 issue has been closed as completed, and I just stumbled over some idiosyncrasies with deno install vs deno cache, also in the end with deno serve while using Docker/Podman:

Is there any news on this?

The examples with deps.ts without further explanation how to use this seems very counterintuitive in the age of deno.json.