module: subpath folder mappings EOL

[guybedford]

This removes support for subpath folder mappings, turning the runtime deprecation into an end of life feature.

For packages that previously relied on "exports": { "./subpath/": "./subpath/" } working, these packages will now effectively either get the next best exports match or an export not defined error.

Patterns supporting trailing / matches are still supported with these cases continuing to be deprecated as per that deprecation path. This PR is distinct from #40117.

Because package imports did not ship with trailing / pattern matches, that same deprecation path turns out not to be necessary for imports as that deprecation only affected one release so far.

The benefit of this deprecation is spec and implementation simplification.

[guybedford]

@nodejs/modules if we want to land this for v17, the cutoff is Tuesday. Alternatively this can wait until v18.

[ljharb]

I think it should wait. I’m very concerned about packages like mine that need to support every node minor, not just the latest ones, that currently have to either use directory mappings or would have to list thousands of export paths. This removal would force the latter if i wanted to be compatible with both this version and one of those node minors.

[guybedford]

@ljharb given that the warning is visible to all users, do you publish a package that just has a visible warning for those imports?

Or are you shipping subpaths along with patterns so that the warning doesn't apply? Note that the EOL does not throw here so backwards compat will still work - the EOL just entirely removes the logic from applying.

[ljharb]

@guybedford currently I removed "exports" entirely because of the current state of things. To re-add it, I'd want to be sure that the latest major of every node had no warnings, and the latest minor of every node worked, even if with warnings.

If this is possible, then I have no concerns, but based on the disruption with es-abstract that I referenced, I'm not confident it will be possible.

[guybedford]

@ljharb it sounds then like you are arguing against the runtime deprecation that was previously landed in #37215, and not this EOL PR?

It feels like recently all these discussions have been re-fleshing out past decisions...

[ljharb]

@guybedford for one, many of these "past decisions" were made without fully understanding the consequences, including subpath pattern trailers, so it's wise to revisit them in light of the new information.

Yes, I'd prefer to have avoided runtime deprecation warnings to consumers that are not actionable to them; i think that's incredibly harmful to the ecosystem. However, at least things still work, which is the much more important concern. This PR would make them no longer work at all.

[guybedford]

It would be great to have more feedback on this one if possible @nodejs/modules.

[guybedford]

many of these "past decisions" were made without fully understanding the consequences, including subpath pattern trailers, so it's wise to revisit them in light of the new information.

@ljharb while this deprecation has been reflected over a large number of discussions and PRs over the past year, I can appreciate that with so many decisions, discussions and PRs to track it is difficult to fully follow implications until they happen sometimes and this may be one of those cases.

Regardless, the runtime deprecation has been in place for a year now, and the third-party runtime deprecation for 6 months, both of which have laid the way for this PR.

I can appreciate wanting to bring new points to the argument, but it is difficult when your aim of supporting every patch version of Node.js simply makes it not possible to support certain variations of features that can be supported by restricting to semver solutions, and holding all arguments to that point does make progression on these discussions difficult, so I'm not sure what further to say here.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[bmeck]

I do think given the alternative being viable using * and occasional direct path listing this seems a great change. It reduces the overall complexity of the system and makes it match across both imports and exports.

[nodejs-github-bot]

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