You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored
fix(turbopack): add get_relative_request_to for paths used as module requests (#98497)
### What?
Adds `get_relative_request_to`, next to `get_relative_path_to`, for
callers that need a relative
path they can hand to the resolver as a module request. It returns
`./c`, `../c` or `.`, where
`get_relative_path_to` returns `c`, `../c` or `.`.
Fixes `import.meta.glob`'s `base`-relative keys, which currently come
back without the leading `./`:
`{ base: '../outside' }` produces `one.js` where Vite (and our own docs,
and the existing execution
fixture) expect `./one.js`. That fixture is failing on `canary` today;
it passes here unchanged.
### Why?
The `./` prefix is not decoration — it is what makes a string a
*relative* request. Without it, `c`
resolves as the package `c` rather than the file next to `from`.
`get_relative_path_to` stopped emitting the prefix for a path below
`from`, and every caller that
builds a request had to add it back by hand. Eight of them do, each with
the same three lines. That
works, but it puts the requirement in the call sites instead of the API,
and nothing tells a new
caller that it exists — so the ninth request-building call site,
`import.meta.glob`'s `base`-relative
key, was written without it and silently produced the wrong keys. The
two changes were authored
independently and each was green on its own; only together do they
produce the bug, which is why CI
caught it on `canary` rather than on either pull request.
Rather than add a tenth hand-written prefix, this makes "give me a
request" something you can ask
for. The failure mode it removes is the silent one: a caller that
forgets is no longer possible,
because the choice is now the function you call.
### How?
`get_relative_request_to` shares its traversal with
`get_relative_path_to` through one private
helper, so the two can't drift; the only difference is whether a result
that would be bare gets the
prefix. `get_relative_path_to` keeps its signature and behaviour
exactly, including the fast path
that returns `target` by reference when `from` is empty — the request
form can't borrow there, and
the unit tests assert that difference so the fast path isn't reused by
mistake. `FileSystemPath`
gains the matching method.
The eight hand-written prefixes now call the new function and drop their
snippets. Deciding which
call sites to convert needed care, because the callers of
`get_relative_path_to` genuinely want
different things, and the ones that want a plain path deliberately keep
it:
- source-map paths reported back to the client,
- the Next.js template expander, whose invariant check expects the bare
form,
- the paths written into NFT files, which are data rather than requests.
Two locals that hold requests rather than paths are renamed accordingly,
and one leftover
`strip_prefix("./")` is removed — it had become a no-op undoing a prefix
that is no longer produced.
### Testing
The `import-meta-glob-relative` execution fixture already asserts the
correct keys and currently
fails, so the fix is verified by that fixture passing **unmodified** —
its expectations were right
all along.
The unit test that covered these cases before the prefix went away is
restored, now run against both
functions and against `FileSystemPath`, which had been left with no
coverage of either method. Its
original assertions turn out to describe the request form exactly, so
they pin that
`get_relative_request_to` reproduces the earlier contract rather than
merely resembling it.
Beyond that: the full `turbopack-tests` suite, and the `next-server-nft`
and `next-taskless` tests,
which are what would break if a call site that wants a plain path had
been converted by mistake.
<!-- NEXT_JS_LLM -->
<!-- fleet 3acc7e63-52a8-4472-89cd-b1bbb8ad59fa -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
0 commit comments