node v13.0-v13.1 errors on require of a module with "exports" defined

[ljharb]

I get this error: Error: Package exports for 'path/to/package' do not define a valid '.' target

when, in the node v13.1 repl (where the flag should be required), I have:

     "main": "index",
     "exports": {
         ".": {
             "default": "./node.js"
         }
     },

I would have expected "exports" to have no effect prior to v13.2 when no modules flag is provided. It throws for me on v13.0 and v13.1, although not on v12.

This seems like a pretty serious back compat issue.

[ljharb]

(When I switch it to ".": "./node.js" it is requireable on v13.0 and v13.1)

[ljharb]

cc @guybedford @MylesBorins

[MylesBorins]

Definitely seems like a bug to dig into, but afaik we don't have a "backwards compat" contract for any version of "Current". That is part of the reason for the release line. Are there any issues with 12.x?

…

On Mon, Nov 25, 2019, 2:04 PM Jordan Harband ***@***.***> wrote: (When I switch it to ".": "./node.js" it is requireable on v13.0 and v13.1) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#446?email_source=notifications&email_token=AADZYV4VMCOOYCLZTLVOR6TQVQOURA5CNFSM4JRNKIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFDOU2Q#issuecomment-558295658>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYVYLFSWR5TN24SCON4TQVQOURANCNFSM4JRNKIGA> .

[ljharb]

No issues I can find with v12.

I don't mean, a back compat issue that we could fix in older v13 minors (altho that would be ideal), i mean an issue with keeping "exports" moving forward, because it means any package that uses the object form can never work on those two minors of node.

Is there any version of the object form that will work on v13.0 and v13.1?

[MylesBorins]

Tbh I don't think that is something we should care about. Yes we should ensure the changes we make are not semver major, but this is an experimental feature and those are unsupported releases at this point

…

On Mon, Nov 25, 2019, 2:08 PM Jordan Harband ***@***.***> wrote: No issues I can find with v12. I don't mean, a back compat issue that we could fix in older v13 minors (altho that would be ideal), i mean an issue with keeping "exports" moving forward, because it means any package that uses the object form *can never* work on those two minors of node. Is there any version of the object form that will work on v13.0 and v13.1? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#446?email_source=notifications&email_token=AADZYVZBQEXGHJ3WHN7CLNDQVQPBBA5CNFSM4JRNKIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFDO6VY#issuecomment-558296919>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYV7GSPFR7JCVM7UZSQ3QVQPBBANCNFSM4JRNKIGA> .

[ljharb]

The point of a dual mode package is that it's not a breaking change to add ESM to your package; this way it will always be a breaking change for v13.0 and v13.1. Semver does not care about whether a release is "supported" - support (by the platform author) is irrelevant.

[MylesBorins]

Fwiw throwing with the default is likely because that sugar was not supported before 13.2.0

The throwing when no dot declared appears to be similar behavior to what was identified in this issue

nodejs/node#30633

[MylesBorins]

Semver does not care about whether a release is "supported" - support (by the platform author) is irrelevant

Semver minor adds new API surfaces, if you try to use them in earlier versions that will "break". By this definition of semver all minor changes would be considered breaking

13.x is an experimental line that will be EOL in 5 months. We should not limit our implementation to support earlier releases in this release line

[ljharb]

and there's no way we'd be able to do a 13.0 and/or 13.1 backport patch that disabled "exports" checking when the experimental flag was not provided?

[MylesBorins]

I would not want is to. We don't offer that level of support on older minors of current. As we cut a minor almost every two weeks that precident could create significant extra labor for the release team

…

On Mon, Nov 25, 2019, 2:19 PM Jordan Harband ***@***.***> wrote: and there's no way we'd be able to do a 13.0 and/or 13.1 backport patch that disabled "exports" checking when the experimental flag was not provided? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#446?email_source=notifications&email_token=AADZYVZHDOXUWNLL54ZP643QVQQMBA5CNFSM4JRNKIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFDQALY#issuecomment-558301231>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYV77GN4SJP3DJ7TLFOTQVQQMBANCNFSM4JRNKIGA> .

[ljharb]

What this means, effectively, is that if I ever add "exports" to my package.json with the object form in ., I can never support node v13.0 or v13.1 - thus, as a package author, that means I'll probably never use "exports", and thus never use ESM.

[jkrems]

Is it possible to use the following form?

     "main": "index",
     "exports": {
         ".": [{
             "default": "./node.js"
         }, "./node.js"]
     },

I assume most people will not go out of their way to support specific minor versions of non-LTS releases of node but maybe the above will allow more ambitious maintainers to do it?

[ljharb]

@jkrems beautiful :-) that works perfectly and allows the exact support I need.

In that case, especially given Myles' strong resistance to backporting patches into v13.0 and v13.1, I'm content to close this with the understanding that the "best practice" recommendation for maximal backwards compatibility will be to always use an array for . that has the object form, and the string form.