Esbuild fixes #2100
Esbuild fixes #2100
Conversation
1. Externalize backlinks from prebundled deps to the app. This prevents app modules from being sucked into the prebundled deps. 2. Allow non-owned modules (which means .vite/deps) to resolve the app by name. This makes the aforementioned externalized references work when the app builds against them. 3. Allow non-owned modules (which means .vite/deps) to get handleRenaming support. This was necessary because virtual pair components can get invented inside vite/deps, and the virtual pair template contains an import of @ember/component. 4. Change the path structure for virtual pair components to no longer include a notional directory. This solves the problem of esbuild not wanting to resolve things from notional directories.
| // } | ||
|
|
||
| if (!pkg.hasDependency(packageName)) { | ||
| if (!pkg?.hasDependency(packageName)) { |
There was a problem hiding this comment.
This is where we're allowing a missing package to still match renamedModules.
| @@ -1008,6 +1001,10 @@ export class Resolver { | |||
| } | |||
| } | |||
|
|
|||
| if (!pkg || !pkg.isV2Ember()) { | |||
| return request; | |||
There was a problem hiding this comment.
This used to happen before renameModules, etc, now it happens after.
| request = request.rehome(originalFromFile); | ||
| pkg = movedPkg; | ||
| if (pkg) { | ||
| ({ pkg, request } = this.restoreRehomedRequest(pkg, request)); |
There was a problem hiding this comment.
This is just an extraction because fallbackResolve was getting so long.
|
|
||
| let packageName = getPackageName(request.specifier); | ||
| if (packageName === this.options.modulePrefix) { | ||
| return logTransition( |
There was a problem hiding this comment.
This is the new support for app resolving from non-owned or non-ember packages.
| // nothing else to do for relative imports | ||
| return logTransition('fallbackResolve: relative failure', request); | ||
| } | ||
| return this.relativeFallbackResolve(pkg, request); |
There was a problem hiding this comment.
This is another extraction to keep fallbackResolve shorter.
| @@ -172,14 +172,14 @@ function decodeVirtualExternalCJSModule(filename: string) { | |||
| } | |||
|
|
|||
| const pairComponentMarker = '-embroider-pair-component'; | |||
| const pairComponentPattern = /^(?<hbsModule>.*)\/(?<jsModule>[^\/]*)-embroider-pair-component$/; | |||
| const pairComponentPattern = /^(?<hbsModule>.*)__vpc__(?<jsModule>[^\/]*)-embroider-pair-component$/; | |||
There was a problem hiding this comment.
This change in naming means that our virtual pair component is sitting inside a real directory, not an imaginary one. That makes esbuild resolve outbound requests from it correctly.
packages/vite/src/esbuild-request.ts
Outdated
| if (plugins.includes('vite:dep-pre-bundle')) { | ||
| this.phase = 'bundling'; | ||
| } else if (plugins.includes('vite:dep-scan')) { | ||
| this.phase = 'scanning'; | ||
| } else { | ||
| throw new Error(`cannot identify what phase vite is in. Saw plugins: ${plugins.join(', ')}`); |
There was a problem hiding this comment.
This phase detection is extremely tied to vite internals. But we need to distinguish scanning from bundling because scanning already has the entire vite resolver configured whereas bundling is much more primitive and needs us to do more.
packages/vite/src/esbuild-request.ts
Outdated
| @@ -124,6 +151,24 @@ export class EsBuildModuleRequest implements ModuleRequest { | |||
| ) as this; | |||
| } | |||
|
|
|||
| private phase: 'bundling' | 'scanning'; | |||
|
|
|||
| private *extensionSearch(specifier: string): Generator<string> { | |||
There was a problem hiding this comment.
Any integration with @embroider/core resolver must do extension search within its defaultResolve. esbuild is not configured with any during the bundling phase, so we have to do it ourselves.
Because it needs to be available to both the embroider resolver and the template-only-component resolver.
vite devandvite build.@ember/component.Remamining steps: