We need to examine one by one all the module listed as dependencies in the package.json and provide a Deno port for the modules that requires it. All the dev dependencies can be ignored as they are not required to actually run the module.

• "run-exclusive" We do not need to specify a deno port for this module as run-exclusive is a denoified module. We can use this module in our node code and Denoify will automatically replace the import statements when generating the Deno distribution.

• sha3 The module is only used in a file ( hash.ts ) that has a Deno counterpart ( hash.deno.ts ) so we do not need a Deno port for this dependency. See another example in this issue.

• react and react-dom Denoify has builtin import statement replacer for these modules. We do not need to specify any custom port. To know if a module is supported by default by Denoify you can check if there if there is a import statement replacer for it or if the module name is present in the known-ports.json file. For the rest of the tutorial we will assume ts-md5 and js-yaml are NOT known by Denoify.

• "ts-md5" One way to come up with a Deno port of a NPM module is to fork the home repo of the project, here cotag/ts-md5, and setup denoify on the fork. We’ve done it here. It is then possible to specify the fork as a denoPort of the module.
  package.json:

"dependencies": {
    "ts-md5": "^1.2.7"
}

.denoifyrc.json:

"ports": {
    "ts-md5": "garronej/ts-md5"
}

• "js-yaml" If you happen to know an existing port for a module you can directly provide the URL of the index.

package.json:

"dependencies": {
    "js-yaml": "^3.13.1"
},

.denoifyrc.json:

"ports": {
    "js-yaml": "https://deno.land/x/js_yaml_port/js-yaml.js"
}

Be aware though that only deno.land/x and raw.githubusercontent.com URLs are supported and this will only work if the Deno port exposes exactly the same way the NPM module does. For example if the NPM module is supposed to be imported like that import * as Xxx from "xxx" but the Deno port is supposed imported like this: import Xxx from "xxx" it won’t work. If you know your module can be imported in Deno using a pika or jspm URL the solution is to write a custom import statement replacer as shown in the next example.

• "left-pad" Here we don’t want to go into the trouble of porting such a simple module, we can just create a local implementation of leftPad for Deno and ensure it is imported in place of left-pad in the Deno distribution.

src/tools/leftPad.deno.ts:

export function leftPad(str: string, maxLength: number){
    return str.padStart(maxLength);
}

src/bin/denoifyImportReplacer.ts: A import statement replacer is a trap offered by Denoify to give you the chance to specify exactly by what string you want the import/export statements to be replaced. The function will be called against each external import/export, the string returned by the function will replace the import statement in the deno dist. You should return undefined for the statements that you don’t want to manually replace.

see file

.denoifyrc.json: You need to tell denoify where to find your replacer function.

{
    "replacer": "dist/bin/customReplacer.js"
}

This specific custom replacer will make sure that when Denoify run against import * as lb from "left-pad" in src/lib/Cat.ts for example, the import statement be replaced by: import { leftPad as lp } from "../tools/leftPad.ts";
As mentioned earlier, custom replacer can be used to leverage pika and jspm. For example Denoify replace:

import * as ReactDOMServer from "react-dom";

by

// @deno-types="https://raw.githubusercontent.com/Soremwar/deno_types/master/react-dom/v16.13.1/server.d.ts"
import ReactDOMServer from "https://dev.jspm.io/react-dom@16.13.1/server.js";

The replacer that makes this happen can be found here. The version number that is passed to the replacer is the version number of the module installed in the node_modules folder at the time Denoify is run.

For errors related to this implicitly having an any type, replace:

function myFun(a): number{
    this.doSomething(a);
}

by

function myFun(this: any, a: any): number{
    this.doSomething(a);
}

if you don’t know any better.

For errors related to something that can be null or undefined, replace:

x.doSomething();

by

x!.doSomething();

For error related to uninitialized property, replace:

class Foo {
    n: number;
}

by:

class Foo {
    n!: number;
}

For errors relative to name that cannot be found:

describe(...)

declare const describe: any;
describe(...)

For unused variables:

const x=3;

const x=3; x;

Keep in mind that in Deno there is no node_modules sitting on the disk at runtime.

Let’s assume for example that you would like to load a database.json file located at the root of your project. You would write something like this:

src/index.ts

import * as fs from "fs";
import * as path from "path";
import { TextDecoder } from "util";

export function getDatabase(): Record<string,any> {
    return JSON.parse(
        new TextDecoder("utf-8").decode(
            fs.readFileSync(
                path.join(
                    __dirname,
                    "..", "database.json"
                )
            ) as Uint8Array
        )
    );
}

This will work on both Node and Deno when you run your tests but once your module published this won’t work on Deno anymore for the same reason it won’t work in the Browser, the database.json file is present on the disk at runtime.