Switch to using deno to build and develop the site

[taoeffect]

Problem

The Node.js ecosystem is very vulnerable to supply-chain attacks. These threaten (you) the developer, as well as our users.

Solution

See this PR: okTurtles/chel#58

We can replace all of thenpm run * commands with deno task * equivalents that use deno run with appropriate permissions.

Add a deno.json file and remove the tasks from package.json. In fact, I don't think we need a package.json file anymore, a deno.json file will replace it and a deno.lock file will replace package-lock.json when you start using commands like deno task build => deno run --allow-read --allow-write=. npm:astro build.

[SebinSong]

Hi @taoeffect
I'm currently trying to move all the packages specified in 'dependencies/devDependencies' in package.json to imports field in deno.json.

What I've tried is, I ran deno add command (eg. deno add npm:astro) and it did create a deno.lock file and populate it but did not modify deno.json file. Maybe I'm doing something wrong but am curious if this is expected or not. Is it that we need to manually populate the imports field ourselves?

eg.

"imports": {
  "astro": "npm:astro"
}

[taoeffect]

@SebinSong Deno is designed around a completely different workflow when it comes to dependency management. Generally speaking, dependencies are imported in files via their URL. They can also be imported via a prefix like npm:* or node:*.

In Deno 2, they added deno install, deno add, and deno remove.

Note, as this project is moving to deno, and since it is not being published to NPM, we no longer need a package.json file at all. It can be deleted. EDIT: any npm scripts can be migrated to deno tasks in deno.json.

For whatever reason, we now have these deno add/install/remove commands (even though to me they seem a bit unnecessary). They appear to manage the deno.json and deno.lock files.

I would closely read these docs: https://docs.deno.com/runtime/fundamentals/modules/

And for using dev dependencies, see the comment here about adding // dev to deno.json.

[taoeffect]

Also, see this PR for how to harden the usage of deno run commands in deno tasks: okTurtles/chel#58

[SebinSong]

@taoeffect

I thought the job is almost complete to send a PR for. So I ran deno task build command and it seems everything went well except below error.

[ERR_UNSUPPORTED_ESM_URL_SCHEME] Only file and data URLs are supported by the default ESM loader. Received protocol 'virtual'
  Location:
    /Users/macbook/Desktop/Web/Work/podcast/node_modules/.deno/astro@5.12.8_1/node_modules/astro/dist/core/build/generate.js:58:23

...

(You can try deno task build locally after checking out the latest sebin/task/#1-use-deno branch.)

I did some search about it and below explanation I found might be the relevant case for us:

This error typically arises in environments where:

Non-standard module loading mechanisms are in use:
Some tools or frameworks might employ their own module resolution or loading systems that generate "virtual" URLs or paths, which are not directly recognized by Node.js's(Deno in our case) native ESM loader.

Transpilation or bundling processes are involved:
When code is transformed or bundled, especially in server-side rendering (SSR) contexts or build processes, the resulting output might contain references to modules using non-standard URL schemes.

---

Another thing that came up a lot during my search is that people who had similar issue before (with various NodeJS-based front-end projects) resolved this issue by upgrading their nodeJS version to the newer one. This makes me feel maybe it could be that Deno is not an ideal development environment yet for Astro or Vue project and we might need to wait until it becomes mature enough to stably work with frontend JS frameworks.

What's your thoughts?

EDIT:
I've followed through this Doc from Deno documentation: Build Astro with Deno

to see how the build goes if astro project is created from scratch by deno init --npm astro@latest command. But with this setup, the project is not completely npm-free. It has package.json with deno.lock.

[SebinSong]

#1 (comment)

This is a helpful comment BTW.

[taoeffect]

to see how the build goes if astro project is created from scratch by deno init --npm astro@latest command. But with this setup, the project is not completely npm-free. It has package.json with deno.lock.

Well, what happens if you replace the package.json file with a deno.json file and reference the astro dependency inside of the deno.json file instead using a specific version number like I did here?

Does it work?

[SebinSong]

@taoeffect
The same issue still happens with that change:

[taoeffect]

Interesting. Thanks, could you let the Astro team know about this? They would probably be interested to know that their documentation for "Build Astro with Deno" doesn't actually use Deno and that Astro doesn't build with Deno...