denoify: Open Source Build & Deployment

What is denoify?

Denoify is an MIT-licensed TypeScript build tool that takes a TypeScript codebase written for Node.js or the browser and emits a modified copy of the source ready to deploy as a Deno module, aimed at npm package authors who want Deno support without writing and maintaining a separate port.

What it is

Denoify consumes a TypeScript codebase targeted at Node.js, the web, or both, and spits out a modified version of the source files ready to be deployed as a Deno module. It lives in the JavaScript and TypeScript packaging ecosystem, and it replaces the manual alternative: maintaining a hand-written Deno fork of an npm package alongside the original.

The concrete problem is distribution. A package that wants to be consumable from Deno's registry needs a Deno-shaped release, and authors historically paid for that with duplicated code, drift between two trees, and releases kept in step by hand. Denoify generates that output from the single existing codebase, so a module ships to npm and to deno.land/x from one set of sources. Deno's npm compatibility, which lets consumers write import {...} from "npm:your-module@5";, reduced but did not remove the need: Denoify keeps modules usable on earlier Deno versions without npm support and produces a Deno-specific distribution that other Deno modules can depend on.

Key capabilities

Recursively resolves and rewrites dependencies, working out of the box with dependencies that themselves use Denoify, with options for those that will not transpile automatically.
Supports Deno-specific file implementations through the xxx.deno.ts naming convention.
Emits output deployable to deno.land/x, making the module eligible for inclusion as a dependency of other Deno modules.
Preserves compatibility with earlier Deno releases that predate npm module support.
Leaves the existing npm release intact, so adding Deno support introduces no breaking changes for current users.
Addresses Node built-ins explicitly, as reflected in the project's build-tool, deno, jspm, node-builtin, support-deno, and sypack topics.

Who uses it and how

Authors of runtime-agnostic libraries, including EVT, Nano JSX, eta, graphql-helix, tsafe, and Automerge, publish one codebase to both npm and deno.land/x.
Modules that want Deno users to import them directly rather than through the npm: specifier use the generated Deno distribution.
Projects supporting Deno versions older than npm compatibility keep a Denoify-produced build in the release process.
Modules that do not work under Deno out of the box, roughly 10% of npm modules per the README, use xxx.deno.ts files to supply Deno-specific implementations for individual files.
TypeScript sources fit directly; a vanilla JavaScript module must be converted to TypeScript before Denoify applies.

Getting started

The README directs users to the quick start guide at docs.denoify.land for installation and first-run instructions. No standalone npm package, Docker image, or compose file is documented in the available facts.

How it compares

Denoify's own README, in an August 2024 update, advises using JSR, a Deno-team initiative that addresses a broader set of problems; Hono, previously a Denoify user, has migrated to JSR. For projects with no dependencies and no Node built-ins such as fs, https, or process, the README notes that TypeScript's moduleResolution: bundler compiler option removes the need for Denoify entirely.

When to use it — and when not to

There is nothing to host: Denoify is a build tool, and no database, storage, or SMTP service is required to run it. It is the wrong choice for vanilla JavaScript modules, for code that relies on require(), which is not supported, and for modules that read their own bundled files, since fs.readFile() cannot reach files shipped inside a res/ directory under Deno. New projects should weigh the README's own JSR guidance before adopting it.

project readme (upstream, from github) — read inline

🦕 Release on NPM and on deno.land/x with a single codebase🦕

Home - Documentation - Demo repo

August 2024 Update: It's now advisable to use JSR.
JSR, an initiative by the Deno team, addresses a broader set of problems than Denoify.
Hono, which previously used Denoify, has already migrated to JSR.

What it is

A build tool that takes as input a TypeScript codebase that was meant to target node and/or the web and spits out a modified version of the source files ready to be deployed as a Deno module.

what_denoify_does

NOTE: Denoify is capable of recursively resolving dependencies!
It works out of the box with dependencies that uses denoify and there are many option for dealing with dependencies that won't transpile automatically. See specific documentation

This tool is mainly for NPM module publisher, to enable them to bring first-class citizen Deno support to their modules and do so without introducing breaking changes.

Deno's Support for NPM Modules: What It Means and the Continued Relevance of Denoify

Deno now supports NPM modules.
This development significantly benefits NPM module authors as it simplifies the process of integrating their modules into Deno.
You simply instruct your users to import your module using the format: import {...} from "npm:your-module@5";.

However, even with this development, there are still compelling reasons to consider using Denoify for your module:

Publishing on deno.land/x: If you aspire to have your module incorporated into other Deno modules, it is crucial to release a Deno-specific distribution. Without it, your chances of significant inclusion are considerably diminished.
Ensuring Retro Compatibility: Denoify ensures your module remains compatible with earlier Deno versions lacking NPM support. This retro-compatibility broadens your module's user base and applicability.
Tailoring Module Adaptations: Not all NPM modules (approximately 10%) will work seamlessly with Deno out of the box. In these cases, Denoify can aid in creating Deno-specific implementations for particular files within your module (xxx.deno.ts).

Therefore, despite Deno's new NPM support, Denoify continues to offer value in ensuring wider compatibility, adaptability, and visibility for your module.

Example of modules using Denoify

Some modules that have been made cross-runtime using Denoify:

Limitations

If your module is vanilla JS it needs to be ported to TypeScript first[^0].
require() is not supported.
You can't fs.readFile() files that are part of the module ( files inside a res/ directory for example ). [^1]

[^0]: Don't be afraid, renaming your source with .ts and dropping some any here and there will do the trick. You will be able to pull it off even if you aren't familiar with typescript. Ref

[^1]: In Deno the files that forms your module won’t be pre-fetched and placed in node_module like in node so you won’t be able to access files that are not on the disk.

Get started

🚀 Quick start 🚀

Doing without Denoify

If your project doesn't have any dependencies and isn't utilizing Node built-ins (e.g., fs, https, process), you have an alternative to Denoify. You can make use of the TypeScript compiler options moduleResolution: bundler and allowImportingTsExtensions: true. For more information, see this comment.

Please note that this technique requires the addition of .ts extension to your source file imports. This could lead to potential compatibility issues with certain tools, and require an adjustment period.

What's new

NEW IN v1.6.0

Support for Deno environnement variable (Deno.env('XYZ')). Thank you to @dancrumb for this feature. See issue

NEW IN v1.3.1

Denoify now has a proper documentation website!

NEW IN v1.3

Support for // @denoify-line-ignore special comment.

NEW IN v1

import express from "express"; automatically converted into:
import express from "npm:express@5";
(See this update)
Most project will now transpile successfully out of the box.

NEW IN v0.10

Mitigate the risk of comment being accidentally modified.
Possibility to specify output directory in the package.json's denoify field. See doc.
Support module augmentation: declare module .... Example
Possibility to explicitly tell where the index.ts is located in the source. Doc

NEW IN v0.9

tsconfig.json can be absent if outputDir is specified. See @zxch3n's PR
Enable to configure the name of the output dir. It no longer has to be deno_dist. See @zxch3n's PR

NEW IN v0.7

Support for esm modules. See issue. Thanks to yandeu.

NEW IN v0.7

Support for workspaces where node_modules are located in a parent directory.
Thx @hayes See issue
Add basic support for child_process.spawn (#785)

NEW IN v0.6

Built in support for graphQL.
See how graphql-helix got graphql working before v0.6 using a custom replacer referenced in the package.json.
You can do the same with other modules using skypack.dev or jspm
It is now possible to use console.log() in custom replacers to help debug.
Some support for crypto node builtin.

NEW IN v0.5 Breaking changes

All Denoify parameters are now gathered under a uniq "denoify" field.
Possibility to specify which files should be copied to the deno_dist directory (Previously only README.md was copied).
Valid config example

Introduction video

NOTE: New features have been introduced since this meeting was hold

Frequently asked questions

Is denoify free to use?

denoify is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does denoify do?

🦕For NPM module authors that would like to support Deno but do not want to write and maintain a port.

What is denoify written in?

denoify is primarily written in TypeScript. Its source is publicly available at https://github.com/garronej/denoify, and it has 949 GitHub stars.