Build: fully resolve import paths in transpiled files #73822
+48
−2
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 PR implements the same thing as #73422, but as part of esbuild
onResolvecallback, without a separate post-processing step with Babel.Local imports like
import from './proxy'are resolved either to'./proxy.js'or'./proxy/index.js', depending on which file/directory exists. That way the imports become compatible with Node.js ESM import rules, and also with browsers' native ESM import rules. They both require full file paths, without any shortcuts.I originally wanted to eliminate local imports completely in #73516, but that proved too ambitious and risky.
This esbuild approach is very simple and flexible. If we want to, we can easily modify it to make all imports use the
.mjsor.cjsextension. That will be useful for creating fully compliant dual CJS/ESM packages.Before we merge this, I'd like to fine-tune the algorithm a bit. Make sure that special paths like
'.'and'..'are handled correctly, that imports with an existing non-JS extension (likeblock.json) are not handled with this code, etc. But I didn't want to delay the PR further. Let's test and review.