Taquito first class support for deno

[jevonearth]

Deno is a new runtime for JavaScript and TypeScript.

We want:

• To be able to build Taquito in a deno environment
• To run Taquito's integration tests to a deno environment
• For Taquito packages to be published to the deno package registry: https://deno.land/x
• For Taquito users to have an easy and unsurprising experience when building a service on deno using Taquito

See: https://deno.land/

[mweichert]

Posting some thoughts I shared with @jevonearth when investigating how to add Deno as a build target for Taquito. Its important to differentiate between the following:

a) Consuming Taquito with Deno b) Adding Deno as a build target for Taquito

Consuming Taquito with Deno

Using an import map file, its relatively easy to make the following example work: import {TezosToolkit} from '@taquito/taquito'; console.log(TezosToolkit);

To make it work, you would map @taquito/taquito to https://cdn.skypack.dev/@taquito/taquito

As of right now, this won't actually work because Taquito makes use of require() and CJS. However, there are only a few places in various Taquito packages where CJS is used, and so adjusting is not difficult and something I was able to do quickly when prototyping.

Adding Deno as a build target for Taquito

Say you're working on a feature branch in Taquito, and want to target Deno? How do you do that? First, you'll need to write an import map which does the following:

• Maps any third party NPM modules to Skypack. Skypack will take care of converting CJS to ESM, and too, use Deno's polyfills for Node.
• For any first party code, find portable alternatives to any node APIs used, or use the polyfills mentioned above

That gets you most of the way there. However, there's one critical function that Skypack does for you when consuming that you have to do so yourself when targeting - local module resolution. For instance, one thing that Skypack does for you is transpile something like this:

import {split} from './util'

to:

import {split} from './util.ts'

Why? This is part of the ESM spec, and what browsers and Deno expect. They require fully resolved paths.

I'm surprised, but haven't found a third-party tool that does this kind of transpilation other than bundlers which accept TypeScript as input and output JavaScript. However, that has its own problems as the Deno runtime is stricter than the browser and Node. For example, take the following Typescript:

const foobar = (foo: string | undefined) => foo ? foo : "Foo Bar"
console.log(foobar()) // outputs "Foo Bar"

It's a common approach - a function will use a default value if no parameter is given. Running this code using a bundler like Rollup or Webpack produces the following output:

const foobar = foo => foo ? foo : "Foo Bar"
console.log(foobar())

The output is technically valid JavaScript, but it will not compile using Deno. Deno will throw a compilation error: foobar expects 1 argument but was called with 0 arguments.

I had a few ideas how to work around this:

• Is there a tool that outputs TS but resolves the module paths that are missing extensions? I wasn't able to find anything, but I think this is the most ideal. I'm surprised that it doesn't exist already. I suspect that many others would find something like this useful.
• Is there a bundler (rollup, esbuild, etc) that targets Deno? Best as I can tell, there isn't anything like this available
• Is there a bundler plugin that transpiles optional arguments differently? Still looking, but haven't found anything yet. Can I just fork skypack? Nope, it's not open source and the source isn't available

[michaelkernaghan]

general agreement in the team that at this point Deno is not going to be implemented in Taquito.