Deno to npm package build tool.
This tool is under active early development and hasn't been tested in a lot of scenarios. Examine its output thoroughly before publishing. If you encounter any problems or challenges, please open an issue to help us improve it.
Takes a Deno module and creates an npm package for use in Node.js.
There are several steps done in a pipeline:
- Transforms Deno code to Node/canonical TypeScript including files found by
deno test
.- Rewrites module specifiers.
- Injects shims for any
Deno
namespace or other global name usages as specified. - Rewrites Skypack and esm.sh specifiers to bare specifiers and includes these dependencies in a package.json.
- When remote modules cannot be resolved to an npm package, it downloads them and rewrites specifiers to make them local.
- Allows mapping any specifier to an npm package.
- Type checks the output.
- Emits ESM, CommonJS, and TypeScript declaration files along with a package.json file.
- Runs the final output in Node.js through a test runner calling all
Deno.test
calls.
-
Create a build script file:
// ex. scripts/build_npm.ts import { build, emptyDir } from "https://deno.land/x/dnt/mod.ts"; await emptyDir("./npm"); await build({ entryPoints: ["./mod.ts"], outDir: "./npm", shims: { // see JS docs for overview and more options deno: true, }, package: { // package.json properties name: "your-package", version: Deno.args[0], description: "Your package.", license: "MIT", repository: { type: "git", url: "git+https://github.com/username/repo.git", }, bugs: { url: "https://github.com/username/repo/issues", }, }, postBuild() { // steps to run after building and before running the tests Deno.copyFileSync("LICENSE", "npm/LICENSE"); Deno.copyFileSync("README.md", "npm/README.md"); }, });
-
Ignore the output directory with your source control if you desire (ex. add
npm/
to.gitignore
). -
Run it and
npm publish
:# run script deno run -A scripts/build_npm.ts 0.1.0 # go to output directory and publish cd npm npm publish
[dnt] Transforming...
[dnt] Running npm install...
[dnt] Building project...
[dnt] Type checking...
[dnt] Emitting declaration files...
[dnt] Emitting ESM package...
[dnt] Emitting script package...
[dnt] Running tests...
> test
> node test_runner.js
Running tests in ./script/mod.test.js...
test escapeWithinString ... ok
test escapeChar ... ok
Running tests in ./esm/mod.test.js...
test escapeWithinString ... ok
test escapeChar ... ok
[dnt] Complete!
Use the following options to disable any one of these, which are enabled by default:
await build({
// ...etc...
typeCheck: false,
test: false,
declaration: false,
scriptModule: false,
});
Top level await doesn't work in CommonJS/UMD and dnt will error if a top level
await is used and you are outputting CommonJS/UMD code. If you want to output a
CommonJS/UMD package then you'll have to restructure your code to not use any
top level awaits. Otherwise, set the scriptModule
build option to false
:
await build({
// ...etc...
scriptModule: false,
});
dnt will shim the globals specified in the build options. For example, if you specify the following build options:
await build({
// ...etc...
shims: {
deno: true,
},
});
Then write a statement like so...
Deno.readTextFileSync(...);
...dnt will create a shim file in the output, re-exporting the @deno/shim-deno npm shim package and change the Deno global to be used as a property of this object.
import * as dntShim from "./_dnt.shims.js";
dntShim.Deno.readTextFileSync(...);
If you want a shim to only be used in your test code as a dev dependency, then
specify "dev"
for the option.
For example, to use the Deno
namespace only for development and the
setTimeout
and setInterval
browser/Deno compatible shims in the distributed
code, you would do:
await build({
// ...etc...
shims: {
deno: "dev",
timers: true,
},
});
To prevent shimming in specific instances, add a // dnt-shim-ignore
comment:
// dnt-shim-ignore
Deno.readTextFileSync(...);
...which will now output that code as-is.
Set any of these properties to true
(distribution and test) or "dev"
(test
only) to use them.
deno
- Shim theDeno
namespace.timers
- Shim the globalsetTimeout
andsetInterval
functions with Deno and browser compatible versions.prompts
- Shim the globalconfirm
,alert
, andprompt
functions.blob
- Shim theBlob
global with the one from the"buffer"
module.crypto
- Shim thecrypto
global.domException
- Shim theDOMException
global using the "domexception" package (https://www.npmjs.com/package/domexception)undici
- Shimfetch
,File
,FormData
,Headers
,Request
, andResponse
by using the "undici" package (https://www.npmjs.com/package/undici).weakRef
- Sham for theWeakRef
global, which usesglobalThis.WeakRef
when it exists. The sham will throw at runtime when callingderef()
andWeakRef
doesn't globally exist, so this is only intended to help type check code that won't actually use it.webSocket
- ShimWebSocket
by using the ws package.
If you only want to shim Deno.test
then provide the following:
await build({
// ...etc...
shims: {
deno: {
test: "dev",
},
},
});
This may be useful in Node v14 and below where the full deno shim doesn't always work. See the section on Node v14 below for more details
In addition to the pre-defined shim options, you may specify your own custom packages to use to shim globals.
For example:
await build({
scriptModule: false, // node-fetch 3+ only supports ESM
// ...etc...
shims: {
custom: [{
package: {
name: "node-fetch",
version: "~3.1.0",
},
globalNames: [{
// for the `fetch` global...
name: "fetch",
// use the default export of node-fetch
exportName: "default",
}, {
name: "RequestInit",
typeOnly: true, // only used in type declarations
}],
}, {
// this is what `blob: true` does internally
module: "buffer", // uses node's "buffer" module
globalNames: ["Blob"],
}, {
// this is what `domException: true` does internally
package: {
name: "domexception",
version: "^4.0.0",
},
typesPackage: {
name: "@types/domexception",
version: "^4.0.0",
},
globalNames: [{
name: "DOMException",
exportName: "default",
}],
}],
// shims to only use in the tests
customDev: [{
// this is what `timers: "dev"` does internally
package: {
name: "@deno/shim-timers",
version: "~0.1.0",
},
globalNames: ["setTimeout", "setInterval"],
}],
},
});
Custom shims can also refer to local or remote modules:
await build({
// ...etc...
shims: {
custom: [{
module: "./my-custom-fetch-implementation.ts",
globalNames: ["fetch"],
}, {
module: "https://deno.land/x/some_remote_shim_module/mod.ts",
globalNames: ["setTimeout"],
}],
},
});
Where my-custom-fetch-implementation.ts
contains:
export function fetch(/* etc... */) {
// etc...
}
This is useful in situations where you want to implement your own shim.
In most cases, dnt won't know about an npm package being available for one of your dependencies and will download remote modules to include in your package. There are scenarios though where an npm package may exist and you want to use it instead. This can be done by providing a specifier to npm package mapping.
For example:
await build({
// ...etc...
mappings: {
"https://deno.land/x/[email protected]/mod.ts": {
name: "code-block-writer",
version: "^11.0.0",
// optionally specify if this should be a peer dependency
peerDependency: false,
},
},
});
This will:
- Change all
"https://deno.land/x/[email protected]/mod.ts"
specifiers to"code-block-writer"
- Add a package.json dependency for
"code-block-writer": "^11.0.0"
.
Note that dnt will error if you specify a mapping and it is not found in the code. This is done to prevent the scenario where a remote specifier's version is bumped and the mapping isn't updated.
Say an npm package called example
had a subpath at sub_path.js
and you
wanted to map https://deno.land/x/[email protected]/sub_path.ts
to that subpath.
To specify this, you would do the following:
await build({
// ...etc...
mappings: {
"https://deno.land/x/[email protected]/sub_path.ts": {
name: "example",
version: "^0.1.0",
subPath: "sub_path.js", // note this
},
},
});
This would cause the following:
import * as mod from "https://deno.land/x/[email protected]/sub_path.ts";
...to go to...
import * as mod from "example/sub_path.js";
...with a dependency on "example": "^0.1.0"
.
To do this, specify multiple entry points like so (ex. an entry point at .
and
another at ./internal
):
await build({
entryPoints: ["mod.ts", {
name: "./internal",
path: "internal.ts",
}],
// ...etc...
});
This will create a package.json with these as exports:
{
"name": "your-package",
// etc...
"main": "./script/mod.js",
"module": "./esm/mod.js",
"types": "./types/mod.d.ts",
"exports": {
".": {
"import": {
"types": "./types/mod.d.ts",
"default": "./esm/mod.js"
},
"require": {
"types": "./types/mod.d.ts",
"default": "./script/mod.js"
}
},
"./internal": {
"import": {
"types": "./types/internal.d.ts",
"default": "./esm/internal.js"
},
"require": {
"types": "./types/internal.d.ts",
"default": "./script/internal.js"
}
}
}
}
Now these entry points could be imported like
import * as main from "your-package"
and
import * as internal from "your-package/internal";
.
To publish an npm
bin package
similar to deno install
, add a kind: "bin"
entry point:
await build({
entryPoints: [{
kind: "bin",
name: "my_binary", // command name
path: "./cli.ts",
}],
// ...etc...
});
This will add a "bin"
entry to the package.json and add #!/usr/bin/env node
to the top of the specified entry point.
You may find yourself in a scenario where you want to run certain code based on
whether someone is in Deno or if someone is in Node and feature testing is not
possible. For example, say you want to run the deno
executable when the code
is running in Deno and the node
executable when it's running in Node.
One option to handle this, is to use the
which_runtime
deno.land/x module which
provides some exports saying if the code is running in Deno or Node.
Another option is to create node and deno specific modules. This can be done by specifying a mapping to a module:
await build({
// ...etc...
mappings: {
"./file.deno.ts": "./file.node.ts",
},
});
Then within the file, use // dnt-shim-ignore
directives to disable shimming if
you desire.
A mapped module should be written similar to how you write Deno code (ex. use
extensions on imports), except you can also import built-in node modules such as
import fs from "fs";
(just remember to include an @types/node
dev dependency
under the package.devDependencies
object when calling the build
function, if
necessary).
Since the file you're calling is a script, simply add statements before and
after the await build({ ... })
statement:
import { build, emptyDir } from "https://deno.land/x/dnt/mod.ts";
// run pre-build steps here
await emptyDir("./npm");
// build
await build({
// ...etc..
});
// run post-build steps here
await Deno.copyFile("LICENSE", "npm/LICENSE");
await Deno.copyFile("README.md", "npm/README.md");
Your Deno tests might rely on test data files. One way of handling this is to copy these files to be in the output directory at the same relative path your Deno tests run with.
For example:
import { copy } from "https://deno.land/[email protected]/fs/mod.ts";
await Deno.remove("npm", { recursive: true }).catch((_) => {});
await copy("testdata", "npm/esm/testdata", { overwrite: true });
await copy("testdata", "npm/script/testdata", { overwrite: true });
await build({
// ...etc...
});
// ensure the test data is ignored in the `.npmignore` file
// so it doesn't get published with your npm package
await Deno.writeTextFile(
"npm/.npmignore",
"esm/testdata/\nscript/testdata/\n",
{ append: true },
);
Alternatively, you could also use the
which_runtime
module and use a different
directory path when the tests are running in Node. This is probably more ideal
if you have a lot of test data.
By default, dnt uses the same search pattern
that deno test
uses to find test files. To override this, provide a
testPattern
and/or rootTestDir
option:
await build({
// ...etc...
testPattern: "**/*.test.{ts,tsx,js,mjs,jsx}",
// and/or provide a directory to start searching for test
// files from, which defaults to the current working directory
rootTestDir: "./tests",
});
To use an import map or deno.json file with "imports"
and/or "scopes"
, add
an importMap
entry to your build object:
await build({
// ...etc...
importMap: "deno.json",
});
Note there is no support for the deno.json importMap
key. Either embed that in
your deno.json or specify the import map in this property directly. Also note
that the deno.json is not auto-discovered—you must explicitly specify it.
-
Ensure your build script accepts a version as a CLI argument and sets that in the package.json object. For example:
await build({ // ...etc... package: { version: Deno.args[0], // ...etc... }, });
Note: You may wish to remove the leading
v
in the tag name if it exists (ex.Deno.args[0]?.replace(/^v/, "")
) -
In your npm settings, create an automation access token (see Creating and Viewing Access Tokens).
-
In your GitHub repo or organization, add a secret for
NPM_TOKEN
with the value created in the previous step (see Creating Encrypted Secrets for a Repository). -
In your GitHub Actions workflow, get the tag name, setup node, run your build script, then publish to npm.
# ...setup deno and run `deno test` here as you normally would... - name: Get tag version if: startsWith(github.ref, 'refs/tags/') id: get_tag_version run: echo ::set-output name=TAG_VERSION::${GITHUB_REF/refs\/tags\//} - uses: actions/setup-node@v2 with: node-version: '16.x' registry-url: 'https://registry.npmjs.org' - name: npm build run: deno run -A ./scripts/build_npm.ts ${{steps.get_tag_version.outputs.TAG_VERSION}} - name: npm publish if: startsWith(github.ref, 'refs/tags/') env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} run: cd npm && npm publish
Note that the build script always runs even when not publishing. This is to ensure your build and tests pass on each commit.
-
Ensure the workflow will run on tag creation. For example, see Trigger GitHub Action Only on New Tags).
You may want to use another Node.js package manager instead of npm, such as Yarn
or pnpm. To do this, override the packageManager
option in the build options.
For example:
await build({
// ...etc...
packageManager: "yarn", // or "pnpm"
});
You can even specify an absolute path to the executable file of the package manager:
await build({
// ...etc...
packageManager: "/usr/bin/pnpm",
});
If you wish to compile with DOM types for type checking, you may specify a "dom" lib compiler option when building:
await build({
// ...etc...
compilerOptions: {
lib: ["es2021", "dom"],
},
});
dnt should be able to target old versions of Node by specifying a
{ compilerOption: { target: ... }}
value in the build options (see
Node Target Mapping
for what target maps to what Node version). A problem though is that certain
shims might not work in old versions of Node.
If wanting to target a version of Node v14 and below, its recommend to use the
Deno.test
-only shim (described above) and then making use of the "mappings"
feature to write Node-only files where you can handle differences.
Alternatively, see if changes to the shim libraries might make it run on old
versions of Node. Unfortunately, certain features are impossible or infeasible
to get working.
See this thread in node_deno_shims for more details.
For only the Deno to canonical TypeScript transform which may be useful for bundlers, use the following:
// docs: https://doc.deno.land/https/deno.land/x/dnt/transform.ts
import { transform } from "https://deno.land/x/dnt/transform.ts";
const outputResult = await transform({
entryPoints: ["./mod.ts"],
testEntryPoints: ["./mod.test.ts"],
shims: [],
testShims: [],
// mappings: {}, // optional specifier mappings
});
use std::path::PathBuf;
use deno_node_transform::ModuleSpecifier;
use deno_node_transform::transform;
use deno_node_transform::TransformOptions;
let output_result = transform(TransformOptions {
entry_points: vec![ModuleSpecifier::from_file_path(PathBuf::from("./mod.ts")).unwrap()],
test_entry_points: vec![ModuleSpecifier::from_file_path(PathBuf::from("./mod.test.ts")).unwrap()],
shims: vec![],
test_shims: vec![],
loader: None, // use the default loader
specifier_mappings: None,
}).await?;