Skip to main content
Module

std/node/README.md

Deno standard library
denoland/deno_std
Go to Latest
File

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 partly
  • assert/strict partly
  • async_hooks
  • buffer
  • child_process partly
  • cluster
  • console partly
  • constants partly
  • crypto partly
  • dgram
  • diagnostics_channel
  • dns partly
  • events
  • fs partly
  • fs/promises partly
  • http
  • http2
  • https
  • inspector
  • module
  • net
  • os partly
  • path
  • path/posix
  • path/win32
  • perf_hooks
  • process partly
  • querystring
  • readline
  • repl
  • 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
  • wasi
  • webcrypto
  • worker_threads
  • zlib
  • node globals partly

Deprecated

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

  • domain
  • freelist
  • punycode

Experimental

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
  • stream/web

CommonJS modules loading

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

import { createRequire } from "https://deno.land/std@0.116.0/node/module.ts";

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");

Contributing

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 run --allow-read --allow-net --allow-write node/_tools/setup.ts

You can aditionally 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 tests in a local environment, try one of the following:

  • Use node/_tools/require.ts as follows(recommended):
$ deno run -A --unstable node/_tools/require.ts /Abs/path/to/deno_std/node/_tools/suites/parallel/test-event-emitter-check-listener-leaks.js
  • Add --only flag to the node/_tools/config.json.
...
  "tests": {
    ...
    "parallel": [
      ...
      "test-event-emitter-add-listeners.js",
      "test-event-emitter-check-listener-leaks.js --only",
      "test-event-emitter-invalid-listener.js",
      ...
    ]
    ...
  }
...

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 https://github.com/nodejs/node/tree/master/test.

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.

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) {
  callback(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.