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

[guybedford]

The semantics of "exports" are that the field is only ever parsed when not null or undefined. When it is parsed, if it is not valid then that behaves as if there are no exports of the package (including the main, since the main is an export).

I think this is actually a docs issue, since "exports": false was a feature before the exports main was fully supported - we previously treated subpaths and the main differently such that exports only applied to subpaths and "exports": false could make sense to disable subpaths.

I've created a docs update in 74206e7 to remove reference to the "exports": false case, and rather encourage using the exports main always as the pattern here.

I think that would make sense as guidance to always encourage setting the exports main as in this docs update.

Thanks for posting @JLHwung this is definitely a confusion that would be good to fix.

[ljharb]

@guybedford when did we discuss changing it? As i recall, it’s supposed to always be passed into Object.keys when it’s non-nullish, making false and true and {} equivalent.

[guybedford]

Yes all non null values *are* equivalent. But it will not revert to the main in all those cases since we made exports a primary definition of the main entry point hence the error.

…

On Fri, Mar 6, 2020 at 18:55 Jordan Harband ***@***.***> wrote: @guybedford <https://github.com/guybedford> when did we discuss changing it? As i recall, it’s supposed to always be passed into Object.keys when it’s non-nullish, making false and true and {} equivalent. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32107?email_source=notifications&email_token=AAESFSQEBHRKF3PKPR3SABTRGETIPA5CNFSM4LCOFUK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOCBYRY#issuecomment-595860551>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESFSQPSI4Y73E37KO5OZLRGETIPANCNFSM4LCOFUKQ> .

[ozanmanav]

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.

This is the fix, I used node13-alpine in the docker file, because of that i was getting this error. Now i fixed to 12.6.1 and error is gone. (althought i upgraded babel to latest )

[guybedford]

There is a Babel bug here that was fixed in a patch. See https://github.com/babel/babel/pull/11006/files.

[JLHwung]

There is a Babel bug here that was fixed in a patch. See https://github.com/babel/babel/pull/11006/files.

That patch is supposed to offer backward compatibility: At that moment exports: false was recommended in docs but it was not supported in node.js 13.0-13.1.

[ljharb]

To support those node versions, you need to use an array, so the object form can fall back to the string form.

[jkrems]

I think in this case, it's enough to just use the string form. The current value:

  "main": "lib/index.js",
  "exports": {
    ".": "./lib/index.js"
  },

Could also be written as:

  "main": "lib/index.js",
  "exports": "./lib/index.js",

[mlittlec]

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.

This is the fix, I used node13-alpine in the docker file, because of that i was getting this error. Now i fixed to 12.6.1 and error is gone. (althought i upgraded babel to latest )

This worked for me too - I moved back to the LTS (12.6.1) version on my Ubuntu install via this command sudo n stable

[bmartel]

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

I ran into this upon upgrading to node 12.6.3 from 10.20.1, just wanted to mention that this definitely resolves my case. I also want to mention for others possibly running @babel/register for server side compilation to ensure it is also upgraded to match otherwise you will continue to get the same error for the server side compilation step. I forgot I even had it which seems to always be the case once something works for a long time 😄.

[smoak]

Just adding that I get this issue with node versions 12.18.0 and 12.17.0 but it does not reproduce with node version 12.16.3. Platform: Linux myarch 5.4.42-1-lts SMP Wed, 20 May 2020 20:42:53 +0000 x86_64 GNU/Linux

[guybedford]

exports: false is the same as exports: {} or having a package that cannot be loaded at all!

You don't want to ever use it.

To give some background here for those interested, in an early iteration of the "exports" field, it used to only provide subpath exports, and work alongside the "main". It was a later change in the development of this field to make it also apply to the main and provide the conditional mapping features to the main. Before it applied to the main "exports": false could be used to indicate a package that was encapsulated and could be only loaded via the main, but since the main was also included in its definition, "exports": false will now not even load the "main".

Any packages published with this pattern are shipping a bug, so you likely want to upgrade any dependency that is using this "exports": false" definition to fix the issue.

There should be enough information in this thread for anyone hitting this issue, closing this as a non-bug.

[BirgitPohl]

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.

Because of this hint I switched from LTS v12.18.2 to LTS v12.16.1 and got this resolved.
I have a clean installation straight from Github.
No changed were made in my repo that worked before and after resolving.

As far as I can read babel has referred to the Node community to resolve this.

[jkrems]

@BirgitPohl I think the babel package is fixed in the latest version (https://github.com/babel/babel/blob/7fd40d86a0d03ff0e9c3ea16b29689945433d4df/packages/babel-helper-compilation-targets/package.json#L13-L15) - or at least should be. If this happens with a different package, it may require a similar fix to its package.json.

[guybedford]

If this version of the Babel helper continues to cause problems one approach might be to land supporting non-object exports as being warnings while behaving as if exports does not exist.