Feature: Deno support

[sambacha]

I am guessing v3 of Hardhat is being planned. With that said It may be benifical to give Deno a serious consideration.

Native web worker support

see this issue about NodeJs having web worker support

sane FFI see https://deno.land/manual/runtime/ffi_api

• If Hardhat is going to adopt a Rust based EVM solution this would be easier I would imagine than working with Nodejs as is

X-Typescript-Types

HRE could adopt providing responses with a custom X-TypeScript-Types HTTP header when the types (.d.ts) is defined. This is useful for deno type checks (link).

Note
The idea being that as solc supports imports via URL, there may be use cases in having type checking work like that (am unsure of this just an idea). This would be for browsers

Example (Browser): pass the ?no-check query to disable the X-TypeScript-Types header if some types are incorrect:

import SafeTransferLib from "https://abi.storage/rari-capital/[email protected]/~/SafeTransferLib?no-check"

see esm.sh/

Possibility for Interoperable packages

All required remote dependencies are referenced in a file called deps.ts and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies. If now for example one remote dependency is used in several files, upgrading to a new version of this remote dependency is much simpler as this can be done just within deps.ts.

/**
 * deps.ts
 *
 * This module re-exports the required methods from the dependant remote module.
 */
 export { SafeTransferLib } from "https://x.nest.land/[email protected]/source/index.js?pin=0x0000DeployedAddress

see https://deno.land/manual/examples/manage_dependencies

Maintain NodeJS Compatibility easily with dnt

Deno to NodeJs dnt allows you to develop your Deno module mostly as-is and use a single Deno script to build, type check, and test an npm package in an output directory. Once built, you only need to npm publish the output directory to distribute it to Node.js users.

WebAssembly and Rust

The old bottleneck for web performance used to be the network. But the new bottleneck for web performance is the CPU, and particularly the main thread. Packets go brrrrrrrr. Really though moving towards decoding wasm vs parsing javascript is where we want to be heading right?

Don't listen to any of this, I just wanted to hear yall's thoughts on the idea, I did not find an issue with respect to the scope of this topic.

Cheers, and happy July 4th!

[github-actions]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: d090669b-9ce7-4068-97dd-943e747a5912

[alcuadrado]

Hey @sambacha,

Thanks for this and the other issues/PRs that you opened. Now that 2.10 is out will evaluate all of them.

I follow the deno ecosystem a bit, and I'm impressed with its progress. I haven't thought about how packages can work both in deno and node, but thanks for the pointer.

Currently, Hardhat heavily depends on some node specific behavior. The major examples are the plugin system depending on how modules are loaded and cached, and Solidity dependencies on node's resolution algorithm. We consider both to be somewhat undesirable and we want to change them. If in the process we can make HH compatible with deno, that'd be great.

[sambacha]

Hey @sambacha,

Thanks for this and the other issues/PRs that you opened. Now that 2.10 is out will evaluate all of them.

I follow the deno ecosystem a bit, and I'm impressed with its progress. I haven't thought about how packages can work both in deno and node, but thanks for the pointer.

Currently, Hardhat heavily depends on some node specific behavior. The major examples are the plugin system depending on how modules are loaded and cached, and Solidity dependencies on node's resolution algorithm. We consider both to be somewhat undesirable and we want to change them. If in the process we can make HH compatible with deno, that'd be great.

Yup, I think actually adopting a new cache system would be the biggest boost given the benchmarks I have seen. The Deno stuff as you pointed out is not worth the squeeze.

Now that EthereumJs is ESM compatible, maybe some potential avenues there.

Congrats on the new release btw!

[stavalfi]

The community asks for it!

[StrawberryChocolateFudge]

I give a bump to this. Hardhat would be great with Deno!
The permission management would help avoid future supply-chain attacks, so less DeFi hacks and compromised private keys, if you ask me!

Deno supports importing node_modules now so it should be possible to use hardhat with it and with the permission management I don't need to trust in dependencies. I can verify my app is not doing stuff I don't grant explicit access for.

[cdesch]

bumping this again for support for Deno 2.0

[SebastienGllmt]

I'm trying Deno v2 support for Hardhat v3 at the moment, but there are some Deno issues that stop it from working:

1. tsx usage is blocked on node:module register is not a function denoland/deno#23201
2. forge support is blocked until any one of the following is added to Deno
   1. Local node module (not npm registry) does not load with --node_modules-dir flag denoland/deno#18474
   2. Support github: specifiers in dependencies and package.json denoland/deno#18478
   3. (hackily supportable with npm patch support) Tracking: stabilization of "patch" feature denoland/deno#25110

[kanej]

I'm trying Deno v2 support for Hardhat v3 at the moment, but there are some Deno issues that stop it from working:

1. `tsx` usage is blocked on [node:module register is not a function denoland/deno#23201](https://github.com/denoland/deno/issues/23201)

2. `forge` support is blocked until any one of the following is added to Deno
   
   1. [Local node module (not npm registry) does not load with --node_modules-dir flag denoland/deno#18474](https://github.com/denoland/deno/issues/18474)
   2. [Support `github:` specifiers in dependencies and package.json denoland/deno#18478](https://github.com/denoland/deno/issues/18478)
   3. (hackily supportable with npm patch support) [Tracking: stabilization of "patch" feature denoland/deno#25110](https://github.com/denoland/deno/issues/25110)

Thanks for the details @SebastienGllmt, and for working through the blockers. Super helpful as always.

We have worked in Hardhat 3 to significantly reduce the surface area of our Node API usage. The intention being to move us closer to supporting other runtimes. However this is a longer term objective and it is not an explicit goal of Hardhat 3 to run under deno or other runtimes.

[SebastienGllmt]

tsx usage is blocked on

I noticed that you can bypass this issue entirely if you just comment out this line: https://github.com/NomicFoundation/hardhat/blob/v-next/v-next/hardhat/src/internal/cli/main.ts#L102

Note that this register() function is only called because of this default command line argument, and as far as I can tell register here is just a no-op (possibly leftover from hardhat v2 that used this functionality)

I tried disabling this line and building & plugins still work for me. It could be that (modulo the forge issue that can be hackily worked around) we might actually only be a single line change away from Deno support for hardhat v3

[alcuadrado]

That's really interesting! Thanks for trying it out! I'm not against small changes like that in a best-effort approach. As @kanej mentioned, we'll first focus on shipping v3 before expanding to other runtimes, but we are intentionally relying less on node-specific apis.

How can we detect if the system is running on Deno to avoid calling register? Is there a way to do it without adding dependencies?

[SebastienGllmt]

How can we detect if the system is running on Deno to avoid calling register?

Yes, I tested that the following works as well

// register is not supported in Deno: https://github.com/denoland/deno/issues/23201
if (typeof Deno === "undefined") {
  if (options.registerTsx) {
    register();
  }
}

It would be nice to confirm that register really isn't required for anything, but everything seems to work without it and register is used nowhere in the v3 folders (only in v2) so I feel like it should be safe to skip (or remove entirely)