Build options

The Denoify configurations used to be specified in the package.json file. It's still supported for legacy reasons but you are now encoraged to use a configuration separate configuration file.
The configuration file as shown when using the vscode-icons extension (soon)
Denoify be looking at the root of your project for a denoify.config.js (or a denoify.config.json) configuration file.
You can set it up this way:
// @ts-check
/** @type { import('denoify/lib/config/parseParams').DenoifyParams } */
const config = {
//...your options
module.exports = config;
With the @type annotation you'll get type safety
Following is the type definition of the object expected to be represented in the denoify configuration file:
export type DenoifyParams = {
replacer?: string;
ports?: {
[portName: string]: string;
out?: string;
index?: string;
includes?: (
| string
| {
src: string;
destDir?: string;
destBasename?: string;
(It's defined here in the code)


By default Denoify will generate the deno distribution in deno_dist or deno_lib depending on whay you have in your tsconfig.json.
If you want for example your dist to be generated in a deno dir instead you would use:
"out": "./deno"


Usually the index of your module is specified in the main field of your package.json. If for some reason Denoify doesn't manage to locate this file you can tell explcitely what file should be made the mod.ts file:
"index": "./src/foo.ts"


Specify what files should be copied over to the deno_dist directory. By default it's the and the LICENSE file.
More info here.


It let you point to a custom function that will intercept how Denoify replace the imports statement of external module.
It's usefull if you know the existence of a port for a specific library. For example Denoify support React out of the box thanks to a builtin replacer we have for it.
Using a replacer is very powerfull but very tricky as well, you should avoid it if you can.
Here you have a concrete usage example ins the demo repo.


By default, if you don't specify any ports and, let's say, you have js-yaml in your dependency pinned at the version 4.1.0 in your package-lock.json or yarn.lock.
Denoify will replace:
import { load } from "js-yaml";
import { load } from "npm:[email protected]";
This will work with version of Deno new enough to have NPM support but you probably want to have shipping with a dependency on NPM.
More info here.

There is an existing port on

If you know that a port exists on you can specify it:
"ports": {
"js-yaml": ""
In this situation the previous import statement will be replaced with:
import { load } from "[email protected]/js-yaml.js";
Denoify will do it's best to resolve to the version closest to the one that you have pinned. In this case it will fail to find 4.1.0 so it will take the latest that is 3.14.0.
Now what if there is no existing port?

You Denoify the dependency yourself in a fork

Don't do that unless you have tried everything else. It's usually much easier to just use a .deno.ts file.
"ports": {
"ts-md5": "garronej/ts-md5"
The following import:
import { Md5 } from "ts-md5";
Will be transformed into:
import { Md5 } from "";
More details here.