module: empty fallback and null exports as not exported

[guybedford]

This PR includes two changes to exports edge cases:

1. Empty array mappings ("./subpath": []) to throw ERR_PACKAGE_PATH_NOT_EXPORTED.
2. null targets ("./subpath": null) as also throwing ERR_PACKAGE_PATH_NOT_EXPORTED.

This comes out of the discussion in jkrems/proposal-pkg-exports#46 where the feature is blacklisting subdirectories via eg:

{
  "exports"; {
    "./features/": "./dist/features/",
    "./features/private/": null
  }
}

Both of the above cases would then result in conditional object checks falling through (whereas the current ERR_INVALID_PACKAGE_TARGET for both does not).

There is likely still some discussion to be had here:

• Currently empty array mappings are treated as invalid meaning that they always throw as a sort of package author validation step since there's no real reason to use them. Either error can in some way be seen as consistent though - [[]] will throw the same error regardless. So it likely is about what is best for usability and what will more likely match import maps.
• null in import maps was originally proposed to match the semantics of [], so should likely follow the above.

Questions:

• Do we want to support this use case?
• Does it make sense to support it via null?
• If so, should [] follow this same error?

I tend to think yes, but let's discuss in the meeting further.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[guybedford]

/cc @nodejs/modules-active-members

[jkrems]

Thanks for adding this! It feels more consistent.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/30799/

[MylesBorins]

From modules team discussion today it seems fine and "we should just do it"

[guybedford]

Landed in e767ed0.