Denoify

The Node to Deno transpile

README


denoify


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


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:

1. 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.

2. 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.

3. 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](https://docs.denoify.land/.deno.ts-files)).

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

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 🚀](https://docs.denoify.land/)

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 beforev0.6 using a custom replacer
    referenced in the [package.json](https://github.com/contrawork/graphql-helix/blob/79e863288a93d1b491caeca32a4124f97465d5a6/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 forcrypto 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).  

Introduction video


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