is a very popular tool used by most of Node projects. Let’s run eslint using Deno in Node compatibility mode. Assuming that eslint is already installed locally (either using npm install eslint or yarn install eslint) we can do so like:

    ⚠️ Notice that ESLint is run with limited set of permissions. We only give it access to the read from the file system, write to current directory and access environmental variables. Programs run in compatility mode are subject to Deno’s permission model.

    When using compatibility mode there Deno does a few things behind the scenes:

    • Node built-in modules are set up and made available to import statements and require() calls. Following calls will return appropriate Node modules polyfilled using std/node:

      • import fs from "fs";
      • import os from "node:os";
      • const path = require("path");
      • const http = require("node:http");

    • Deno will support Node resolution algorithm so importing packages using “bare” specifiers will work. For details on how module resolution works check Node documentation on and ES modules.

    is implemented as in Node and there should be no observable differences.

    ES module resolution is implemented on top of Deno’s regular ESM resolution, leading to a few additional properties compared to Node:

    • In addition to file: and data: URL schemes supported in Node; , https: and blob: URL schemes will work in the same way if you used Deno without compatibility mode.

    • Deno respects field in package.json; in addition to conditions recognized by Node, "deno" condition can be used. This property is useful to the package authors who want to provide separate entrypoint optimized for use with Deno. As an example, imagine that your package uses node-fetch. By providing a conditional "deno" export, you can add an entrypoint that doesn’t depend on node-fetch and instead uses built-in fetch API in Deno.

    Following built-in Node modules are currently supported:

    • assert (partly)
    • buffer
    • console (partly)
    • constants
    • crypto (partly)
    • child_process (partly)
    • dns (partly)
    • events
    • fs (partly)
    • fs/promises (partly)
    • http (partly)
    • module
    • net (partly)
    • (partly)
    • path
    • perf_hooks (partly)
    • process (partly)
    • readline (partly)
    • stream
    • string_decoder
    • sys (partly)
    • timers
    • timers/promises
    • tty (partly)
    • url (partly)
    • util (partly)
    • worker_threads (partly)

    Following modules are not yet implemented:

    • cluster
    • dgram
    • http2
    • https
    • repl
    • tls
    • zlib

    If you try to run Node code that requires any of the not implemented modules, please open an issue in https://github.com/denoland/deno_std/issues with example code.

    Currently, the compatibility mode does not support TypeScript.

    In the long term, we’d like to provide ability to consume TypeScript code authored for the Node runtime.