module: support pattern trailers#39635
Closed
guybedford wants to merge 5 commits intonodejs:masterfrom
Closed
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This implements an extension to exports (and imports) patterns to support LHS matches consisting of trailing strings.
The use case for this came out of discussion with @ljharb, in order to support packages that want to provide "exports" support while enabling subpaths that can support both extensioned and unextensioned forms.
For example, with this PR, the following exports field can be used to expose a features folder with optional extensions:
{ "exports": { "./features/*": "./features/*.js", "./features/*.js": "./features/*.js" } }While we would still encourage package authors to decide on a single pattern, often packages don't have a choice when backwards compatibility is required, so this can also allow for smoother interface transitions if deprecating one or the other pattern as well.
This was left out of the initial implementation to keep the initial implementation as simple as possible. Most of the work is just clearly defining pattern specificity and handling edge cases.
This PR also refines the following edge cases:
"/"exports that resolve to files will now give the trailing "/" deprecation warning."./x/"and"./x*", the second pattern will take precedence over the path for resolving./x/yaccording to the specificity rules.*can't be matched in patterns, so given"exports": { "./*/*.js": "./*.js" }this will no longer matchimport './*/x.js'and instead throw an unexported error. It is of course possible to resolve a*as part of the user specifier component, it just won't be supported as a string character in exports.