denoland/deno · warning

Warning: Not implemented: ${msg}

Error message

Warning: Not implemented: ${msg}

What it means

Deno's node-compat layer ships some Node APIs as warning stubs: calling them runs warnNotImplemented(msg) in ext/node/polyfills/_utils.ts, which prints this message and returns instead of throwing. The named API exists for import compatibility but does nothing under Deno. Your code continues running with silently missing behavior.

Source

Thrown at ext/node/polyfills/_utils.ts:54

  | "ucs2"
  | "ucs-2"
  | "base64"
  | "base64url"
  | "latin1"
  | "hex";

type Encodings = BinaryEncodings | TextEncodings;

function notImplemented(msg: string): never {
  throw new ERR_NOT_IMPLEMENTED(msg);
}

function warnNotImplemented(msg?: string) {
  const message = msg
    ? `Warning: Not implemented: ${msg}`
    : "Warning: Not implemented";
  // deno-lint-ignore no-console
  console.warn(message);
}

type _TextDecoder = typeof TextDecoder.prototype;
const _TextDecoder = TextDecoder;

type _TextEncoder = typeof TextEncoder.prototype;
const _TextEncoder = TextEncoder;

// API helpers

type MaybeNull<T> = T | null;
type MaybeDefined<T> = T | undefined;
type MaybeEmpty<T> = T | null | undefined;

function intoCallbackAPI<T>(
  // deno-lint-ignore no-explicit-any
  func: (...args: any[]) => Promise<T>,
  cb: MaybeEmpty<(err: MaybeNull<Error>, value?: MaybeEmpty<T>) => void>,

View on GitHub (pinned to 9ad36f7a2c)

Solutions

  1. Identify the API named in the message and check Deno's node-compat issue tracker for its implementation status
  2. Replace the call with a supported equivalent: a Deno-native API or another implemented node: module path
  3. Upgrade Deno, since node coverage expands every release
  4. If the caller is third-party and unfixable, isolate it in a subprocess/worker where the no-op is harmless, and verify the feature it guards is not needed

Example fix

// before
import process from "node:process";
process.report?.writeReport("./report.json"); // Warning: Not implemented: ...

// after: use the supported native path for the same goal
// e.g. diagnostics via deno CLI flags instead:
//   deno run --v8-flags=--dump-counters app.js
// or gate the call on a known-good Deno version and skip it otherwise
Defensive patterns

Strategy: type-guard

Type guard

// gate node APIs with known-stubbed surfaces on a Deno version check
function nodeApiLikelyImplemented(minDeno: string): boolean {
  const cur = Deno.version.deno.split(".").map(Number);
  const min = minDeno.split(".").map(Number);
  return cur[0] > min[0] || (cur[0] === min[0] && cur[1] >= min[1]);
}
// e.g. only call the node API when nodeApiLikelyImplemented("2.3.0")

Prevention

When it happens

Trigger: Application or dependency code invokes a node: API whose polyfill is a warn-stub, passing its name as msg (the string is whatever the polyfill supplies, e.g., a module or method name). Typical spots are less-ported surfaces like process.report, some tls/v8/worker options, and niche stream hooks.

Common situations: Running npm CLIs or SDKs under deno run/deno compile that touch uncommon Node APIs; libraries that feature-detect with typeof checks (the stub is a function, so detection passes) and then call into nothing; upgrading a dependency that starts using a newly referenced Node API.

Related errors


AI-assisted analysis of denoland/deno@9ad36f7a2c (2026-08-20). Data as JSON: /api/errors/2f44ec8af1ba4b5d. Report an issue: GitHub.