🦕 Support Deno and release on NPM with a single codebase.🦕
What’s new in
v0.11
: Support or partial support fro many new Node API:console
,cluster
,dgram
,dns
,http
,http2
,https
,inspector
,module
,net
,perf_hooks
,readline
,repl
,string_decoder
,sys
,tls
,tty
,v8
,vm
,wasi
,worker_threads
,zlib
.
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.
NOTE: Denoify won’t run on Deno, it is a Node module.
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
If you are just looking for a quick way to load NPM modules in your Deno project
you can check out CommonJS module Loading,
unlike Denoify, it won’t give you types definitions, it will involve node_modules/
and require --allow-read
but it will also be easier to get working.
Some NPM modules can also be imported into Deno using CDN like Skypack (ex Pika) or jspm
checkout Soremwar/deno_types for some examples.
This tool is mainly for NPM module maintainer, to enable them to bring first-class citizen Deno support to their modules and do so without introducing breaking changes.
Motivations
- Although it is quite easy to port a module to Deno no one wants to maintain two codebase.
- Wouldn’t it be great to have a tool able to bring Deno support to NPM modules?
Example of modules using Denoify
Some modules that have been made cross-runtime using Denoify:
- graphql-helix
- EVT
- Nano JSX
- eta
- hono
- tsafe
- @sniptt/guards
- ok-computer
- run-exclusive
- Yolk
- …and many more great modules
Introduction video
NOTE: New features have been introduced since this meeting was hold
Limitations
Coming up next is a detailed guide on how to set up denoify with your project and how to publish on deno.land/x but before anything here are the current limitations you need to be aware of.
- If your module is vanilla JS it needs to be ported to TypeScript first. (1)
- Not all Node’s builtin modules are supported yet. (2) But thanks to the new mechanism,
à la React Native,
that let you have specific deno implementation for some of your files, the
lack of support for
"https"
or"net"
, while being annoying, is no longer a dead end. - If your module has dependencies you will have to enable those dependencies to run on Deno. While well documented, be aware that it is a time consuming process.
require()
is not yet supported.- You can’t (yet)
fs.readFile()
files that are part of the module ( files inside ares/
directory for example ). (4)
(1) 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
(2) You can consult here the current state of the Node’s builtin support.
(4) 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.
Step by step tutorial
Check out this repo to see in practice how to set up Denoify in your project.
GitHub Actions setup
Once you’ll have successfully build your module for Deno you will want to publish it on deno.land/x
to do that in a clean way, without tracking the deno_dist/
on your main branch you’ll need to setup a
CI workflow.
To do that you can use the .github/workflow/ci.yaml
from tsafe, you can copy paste it, it’s portable.
When registering your module on deno.land/x you will need to specify the subdirectory:
GitHub API rate limit exceeded
Deal with If you run Denoify a lot outside of GitHub Actions pipelines you will eventually get the following error:RequestError [HttpError]: API rate limit exceeded for 176.170.197.165. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
.
To fix it, create a GitHub Personal Access Token and provide it as the environnement variable GITHUB_TOKEN
when you run the build tool.
Example:
echo ghp_xn8jsxZrUChs9nmfZPDSmxLrTJPVJy3Sxc5J > ~/.bash_profile
source ~/.bash_profile
npx denoify
What’s new
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
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 thepackage.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 onlyREADME.md
was copied).
Valid config example