fix: supply '.' subpath for backward compatibility with node.js 13.0-13.1

[JLHwung]

Q	A
Fixed Issues?	https://stackoverflow.com/questions/59706130/error-package-exports-for-path-to-project-folder-node-modules-babel-helper-c
Patch: Bug Fix?	Yes
Tests Added + Pass?	Manually tested
License	MIT

The following snippet will throw on Node.js <= 13.2

require("@babel/helper-compilation-targets")

Error: Package exports for '<path_to_project_folder>/node_modules/@babel/helper-compilation-targets' do not define a '.' subpath

This issue is blocking the preset-env users on Node.js 13.0 - 13.1

The issue is from upstream, which was fixed in https://github.com/nodejs/node/pull/29978/files#diff-76195ce57689942222a27f0dbda6d3b7R495 and later shipped in Node.js 13.2.

Since Node 13 is still current, we offer a . subpath for backward compatibility to Node.js 13.0 - 13.1. Technically if users are running at node.js 12 with --experimental-modules on, they will also see this error, but practically it is a rare situation.

I suggest we simply drop node 13.0 - 13.1 support on Babel v8 so we can continue to use exports: false, it is not a big deal because node 13 is not a LTS candidate and will go EOL at June.

[ljharb]

Wouldn’t node 13.3+ have failed with exports false too?

Keeping the dot is the correct change, since exports replaces main.

[JLHwung]

Wouldn’t node 13.3+ have failed with exports false too?

I don't think so. Actually the docs says that exports: false should be specified if

the package does not intend for submodules to be exposed.

When exports: false is specified, node.js will fallback to main field, (link) which exactly fit our need since we are not shipping modern babel builds currently. This behaviour is introduced in Node.js 13.2 so we have to specify a . entry for Node.js 13.0 - 13.2.

[ljharb]

ah, good point.