Skip to main content
GoodFirstPicks
DashboardIssuesReposLeaderboard

GoodFirstPicks by Leaveitblank © 2026

CreatorRequest a RepoPrivacy PolicyTerms of Service
Recommend `node`/`default` conditions instead of `require`/`import` as a solution to the dual package hazard | GoodFirstPicks

Recommend `node`/`default` conditions instead of `require`/`import` as a solution to the dual package hazard

nodejs/node 10 comments 1mo ago
View on GitHub
lowopenScope: somewhat clearSkill match: yesNode.jsJavaScript

Why this is a good first issue

Documentation update to recommend `node`/`default` conditions over `require`/`import`.

AI Summary

The issue suggests updating the Node.js documentation to recommend using `node`/`default` conditions instead of `require`/`import` to avoid dual package hazards. The change involves modifying the packages.md file. The main blocker is the maintainer's concern about documenting opinionated practices that may soon be obsolete.

Issue Description

Affected URL(s)

https://nodejs.org/api/packages.html#dual-package-hazard

Description of the problem

Publishing packages with dual CommonJS and ESM sources, while has the benefits of supporting both CJS consumers and ESM-only platforms, is known to cause problems because Node.js might load both versions. Example:

package.jsonfoo.cjsfoo.mjs
{
  "name": "foo",
  "exports": {
    "require": "./foo.cjs",
    "import": "./foo.mjs"
  }
}
exports.object = {};     
export const object = {};     
package.jsonbar.js
{
  "name": "bar",
  "main": "./bar.js"
}
const foo = require("foo");
exports.object = foo.object;     
// my app

import { object as fooObj } from "foo";
import { object as barObj } from "bar";

console.log(fooObj === barObj); // false?????

The two suggested solutions boil down to "even when you have an ESM entrypoint, still use only CJS internallly". This solves the dual package hazard, but completely defeats the cross-platform benefits of dual modules.

If foo instead used these export conditions:

{
  "name": "foo",
  "exports": {
    "node": "./foo.cjs",
    "default": "./foo.mjs"
  }
}

Then:

  • there would be no dual-package hazard in Node.js, because it only ever loads the CommonJS version
  • there would be no dual-package hazard in bundlers, because they would only ever load either the node version (if they are configured to target Node.js) or the default version (if they are configured to target other platforms).
  • the package solves the dual-package hazard while still providing an ESM-only version

We have been using this node/default patter

GitHub Labels

docgood first issue

Want to work on this?

Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!

Risk Flags

  • opinionated practices
  • potential obsolescence
Loading labels...

Details

Points10 pts
Difficultylow
Scopesomewhat clear
Skill Matchyes
Test Focusedno