Validate exports keys and values

[hybrist]

We currently do not put any restrictions on keys and values beyond "whatever works in the current implementation". There should be a clear, non-ambiguous definition what happens for every possible key and value.

Worth noting that import maps explicitly treat the pattern and specifier values as arbitrary data. They are not restricted to valid filesystem or URL characters:

[hybrist]

Previous discussion: hybrist/proposal-pkg-exports#6

[hybrist]

There's 3 different "data types" at work:

• (Bare) specifier, maybe the concatenation of name and expansion.
• The pattern (or key).
• The target (or value).
• The resolvedURL.

An approach that seems consistent with how import map validation works could be:

1. optional Normalize specifier, e.g. by collapsing directory separators or converting \\ into /.
   This step is mostly relevant to CJS and Windows where we have to support certain existing specifier formats.
2. Parse specifier into name and expansion. Validate name and expansion.
3. Match expansion to a pattern, resulting in a target. Validate target.
4. Apply the pattern, yielding a resolvedURL. Validate resolvedURL.

The nature of the validation (and what a failed validation means) is TBD here.

[hybrist]

Known possible target values:

• string, relative URL starting with ./.
• string, relative URL starting with ../. Current consensus: Disallowed. May throw?
• string, relative URL starting with /. Current consensus: Disallowed. May throw?
• string, absolute URL with a supported scheme.
• string, absolute URL with an unsupported scheme.
• array, each element a non-array and non-null value.
• null, alias for [].
• boolean. TBD.
• number. TBD.
• object. TBD.

[hybrist]

For pattern values, there are few restrictions. Unrecognized patterns would just not do anything helpful. In a way the definition of a useful pattern value is "anything that could be matched by a valid expansion". The only restriction is: target and pattern have to either both end in a slash ("/") or both not end in a slash ("/").

[hybrist]

If we want to prevent easy loopholes, especially on Windows, we would have to do some limited normalization on specifier values before determining the name. We can protect the exports in the following cases, specifically when the specifier is coming from CJS:

• non-exports-pkg/../exports-pkg/foo.js (path traversal loophole)
• exports-pkg\foo.js (Windows loophole)
• @scope\name/foo.js (Windows loophole, scope edition)

In ESM we'd reject those as invalid specifiers, so the issue doesn't exist. But in CJS we generally fall back on the old resolution when no exports are found.

[bmeck]

Why is escaping the current package boundary a "loophole"?

[hybrist]

It's a "loophole" as in "you're still using bare specifiers but you circumvent exports". But I scaled down the language to call out that preventing those circumventions is optional.

[bmeck]

if it is a concern couldn't you negotiate whenever you cross into a package boundary? would be a lot of IO though.

[hybrist]

Yeah, it would also muddy the waters of what exports are. Because right now they don't really apply to "directories" but to "package names". Since this is only an issue in CJS (where we have to support old behavior), I'd rather keep it simple. E.g. "we accept that it's possible" or "we normalize and prevent these known patterns".

[bmeck]

How does this not have the same problem in ESM?

[hybrist]

I thought somebody (@guybedford?) mentioned that we'd throw a ERR_INVALID_MODULE_SPECIFIER for those kinds of specifiers but I can't find any mention of it now. :( So I guess we still have to define behavior for it, either accepting the same kinds of issues as with CJS or making those illegal in ESM (e.g. .. segments and backslashes).

EDIT: The only thing we do reject is backslashes in scopes (Invalid package name '@foo\bar').

[bmeck]

@jkrems of note, | is also a character that seems to be in conflict with import maps/layered API fallback strings

[hybrist]

@bmeck Thanks, I wasn't aware of that! Do you happen to have a link about the pipe / | character in import maps? Tried to search through the usual repos and couldn't find more details.

[bmeck]

@jkrems the conflict actually comes from https://github.com/drufball/layered-apis#solution but the specifiers from layered APIs would be split on | prior to being import mapped