/ std@0.166.0 / node

_crypto654 KB
_fs217 KB
_module12 KB
_process8 KB
_tools2 MB
_util16 KB
integrationtest5 MB
internal_binding496 KB
testdata52 KB
_core.ts1 KB
_events.d.ts27 KB
_events.mjs27 KB
_global.d.ts2 KB
_http_agent.mjs15 KB
_http_common.ts950 B
_http_outgoing.ts29 KB
_next_tick.ts5 KB
_pako.mjs211 KB
_readline_shared_types.d.ts1 KB
_readline.d.ts23 KB
_readline.mjs12 KB
_stream.d.ts52 KB
_stream.mjs89 KB
_test_utils.ts2 KB
_tls_common.ts377 B
_tls_wrap.ts12 KB
_utils.ts6 KB
_zlib_binding.mjs12 KB
_zlib.mjs16 KB
assert.ts23 KB
assertion_error_test.ts5 KB
assertion_error.ts19 KB
async_hooks.ts4 KB
buffer_test.ts15 KB
buffer.ts262 B
child_process_test.ts16 KB
child_process.ts20 KB
cluster.ts2 KB
console.ts563 B
constants.ts2 KB
crypto_test.ts2 KB
crypto.ts10 KB
dgram.ts43 KB
diagnostics_channel.ts340 B
dns.ts27 KB
domain.ts409 B
events.ts303 B
fs.ts6 KB
global_test.ts4 KB
global.ts2 KB
http_test.ts10 KB
http.ts20 KB
http2.ts2 KB
https_test.ts2 KB
https.ts3 KB
inspector.ts3 KB
module_all_test.ts11 KB
module_all.ts7 KB
module_esm.ts23 KB
module_test.ts7 KB
module.ts43 KB
net_test.ts2 KB
net.ts68 KB
os_test.ts5 KB
os.ts10 KB
path.ts167 B
perf_hooks_test.ts2 KB
perf_hooks.ts2 KB
process_test.ts15 KB
process.ts19 KB
punycode.ts282 B
querystring_test.ts595 B
querystring.ts16 KB
readline_test.ts486 B
readline.ts551 B
repl.ts986 B
stream.ts671 B
string_decoder_bench.js41 KB
string_decoder_test.ts6 KB
string_decoder.ts10 KB
sys.ts139 B
timers_test.ts1 KB
timers.ts2 KB
tls_test.ts3 KB
tls.ts2 KB
tty_test.ts1 KB
tty.ts613 B
upstream_modules_test.ts552 B
upstream_modules.ts1 KB
url_test.ts246 B
url.ts43 KB
util_test.ts5 KB
util.ts6 KB
v8.ts2 KB
vm_test.ts1 KB
vm.ts2 KB
wasi.ts183 B
worker_threads_test.ts5 KB
worker_threads.ts7 KB
zlib.ts3 KB

Deno Node.js compatibility

This module is meant to have a compatibility layer for the Node.js standard library.

Warning: Any function of this module should not be referred anywhere in the Deno standard library as it's a compatibility module.

Supported modules

  • assert
  • assert/strict partly
  • async_hooks partly
  • buffer
  • child_process partly
  • cluster partly
  • console partly
  • constants partly
  • crypto partly
  • dgram partly
  • diagnostics_channel
  • dns partly
  • events
  • fs partly
  • fs/promises partly
  • http partly
  • http2
  • https partly
  • inspector partly
  • module
  • net
  • os partly
  • path
  • path/posix
  • path/win32
  • perf_hooks
  • process partly
  • punycode
  • querystring
  • readline
  • repl partly
  • stream
  • stream/promises
  • stream/web partly
  • string_decoder
  • sys
  • timers
  • timers/promises
  • tls
  • trace_events
  • tty partly
  • url
  • util partly
  • util/types partly
  • v8
  • vm partly
  • wasi
  • webcrypto
  • worker_threads
  • zlib
  • node globals partly


These modules are deprecated in Node.js and will probably not be polyfilled:

  • domain
  • freelist


These modules are experimental in Node.js and will not be polyfilled until they are stable:

  • diagnostics_channel
  • async_hooks
  • policies
  • trace_events
  • wasi
  • webcrypto

CommonJS modules loading

createRequire(...) is provided to create a require function for loading CJS modules. It also sets supported globals.

import { createRequire } from "";

const require = createRequire(import.meta.url);
// Loads native module polyfill.
const path = require("path");
// Loads extensionless module.
const cjsModule = require("./my_mod");
// Visits node_modules.
const leftPad = require("left-pad");


Setting up the test runner

This library contains automated tests pulled directly from the Node.js repo in order ensure compatibility.

Setting up the test runner is as simple as running the node/_tools/setup.ts file, this will pull the configured tests in and then add them to the test workflow.

$ deno task node:setup

You can additionally pass the -y/-n flag to use test cache or generating tests from scratch instead of being prompted at the moment of running it.

# Will use downloaded tests instead of prompting user
$ deno run --allow-read --allow-net --allow-write node/_tools/setup.ts -y
# Will not prompt but will download and extract the tests directly
$ deno run --allow-read --allow-net --allow-write node/_tools/setup.ts -n

To run the tests you have set up, do the following:

$ deno test --allow-read --allow-run node/_tools/test.ts

If you want to run specific Node.js test files, you can use the following command

$ deno test -A node/_tools/test.ts -- <pattern-to-match>

For example, if you want to run only node/_tools/test/parallel/test-event-emitter-check-listener-leaks.js, you can use:

$ deno test -A node/_tools/test.ts -- test-event-emitter-check-listener-leaks.js

If you want to run all test files which contains event-emitter in filename, then you can use:

$ deno test -A node/_tools/test.ts -- event-emitter

The test should be passing with the latest deno, so if the test fails, try the following:

To enable new tests, simply add a new entry inside node/_tools/config.json under the tests property. The structure this entries must have has to resemble a path inside

Adding a new entry under the ignore option will indicate the test runner that it should not regenerate that file from scratch the next time the setup is run, this is specially useful to keep track of files that have been manually edited to pass certain tests. However, avoid doing such manual changes to the test files, since that may cover up inconsistencies between the node library and actual node behavior.

Working with child processes ? Use DENO_NODE_COMPAT_URL

When working with child_process modules, you will have to run tests pulled from Node.js. These tests usually spawn deno child processes via the use of process.execPath. The deno executable will use its own embedded version of std modules, then you may get the impression your code is not really working as it should.

To prevent this, set DENO_NODE_COMPAT_URL with the absolute path to your deno_std repo, ending with a trailing slash:

# or
export DENO_NODE_COMPAT_URL=file:///path/to/deno_std/dir/

Then, deno will use your local copy of deno_std instead of latest version.

Best practices

When converting from promise-based to callback-based APIs, the most obvious way is like this:

promise.then((value) => callback(null, value)).catch(callback);

This has a subtle bug - if the callback throws an error, the catch statement will also catch that error, and the callback will be called twice. The correct way to do it is like this:

promise.then((value) => callback(null, value), callback);

The second parameter of then can also be used to catch errors, but only errors from the existing promise, not the new one created by the callback.

If the Deno equivalent is actually synchronous, there's a similar problem with try/catch statements:

try {
  const value = process();
  callback(null, value);
} catch (err) {

Since the callback is called within the try block, any errors from it will be caught and call the callback again.

The correct way to do it is like this:

let err, value;
try {
  value = process();
} catch (e) {
  err = e;
if (err) {
  callback(err); // Make sure arguments.length === 1
} else {
  callback(null, value);

It's not as clean, but prevents the callback being called twice.

Remaining Tests

Node compatibility can be measured by how many native Node tests pass. If you'd like to know what you can work on, check out the list of Node tests remaining here.


Version Info

Tagged at
6 months ago