package.exports: false is not working with module loader

[JLHwung]

Edits:

If you come here via search engine and @babel/* complaints such errors after you upgraded to node.js 12.17.0 or 13.10.0, please update @babel/helper-compilation-targets to latest version.

If you are not using babel directly, please update your build infra (react-scripts, vue-cli and others to name) to latest version. If they doesn't work, the last resort is to remove your package lockfiles and re-install.

--- Original Post ---

• Version: v13.10.1
• Platform: Darwin jh.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64
• Subsystem: ES Modules

What steps will reproduce the bug?

1. Create a package foo, with package.json as

{
  "exports": false
}

2. add a test file test.js.

require("foo")

How often does it reproduce? Is there a required condition?

Must reproduce

What is the expected behavior?

It should load successfully according to the docs

If a package has no exports, setting "exports": false can be used instead of "exports": {} to indicate the package does not intend for submodules to be exposed.

What do you see instead?

It throws

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main resolved in /path/to/foo/package.json

Additional information

exports: {} also throws.
exports: null looks good to me but it is undocumented.

The issue is firstly reported in babel/babel#11216, we had changed exports: false to exports: { ".": "./lib/index.js" } for backward compatibility to Node.js 13.0-13.1. But I don't expect exports: false will break on Node.js 13.10

I am not familiar with ES modules spec. So if this behaviour is intended, please update the docs.

[BassemN]

I'm getting the same error after updating to v13.10.1 so I switched back to LTS v12.16.1 and the error gone.

[BassemN]

I fixed this issue by removing the node_modules directory and package-lock.json file then run npm install to fresh install all packages then the issue was fixed.

[bmhatfield]

I am able to confirm that @BassemN 's advice of removing node_modules and package-lock.json on node v13.10.1 resolved this issue for me as well. Removing only node_modules was not sufficient.

[MylesBorins]

/cc @nodejs/modules

[ljharb]

The exports field value should always be unconditionally passed into Object.keys, such that any primitive value is treated the same as an empty object (which should mean, “defer to main, nothing else is reachable”)

[MylesBorins]

I've got a patch to revert to the behavior documented in the README. It is not clear to me if this was intended / desired behavior change... but I am assuming it is not as the docs were not updated.

I'll open a PR and we can discuss it.

[GeoffreyBooth]

There was a recent change by @jkrems or @guybedford to stop unintended falling back to "main" for unmatched conditions, maybe that introduced a bug?

[MylesBorins]

it seems like behavior has changed for both exports: false and exports: {}.

My original patch doesn't work as it is supposed to unfortunately although the tests I wrote can likely be resused. I found a way to make "false" work, but it completely skips all the exports checks and there is also no support for {}... so I obviously didn't do it right. It's late and I'm done for now, but here is the commit in case anyone wants to pick it up.

[unilynx]

for us this was explicitly triggered by babel 7.8.3 - the exports:false was here: https://github.com/babel/babel/blob/v7.8.3/packages/babel-helper-compilation-targets/package.json

upgrading to 7.8.7 appears to resolve it