fix(@angular/build): prepend deploy-url to file loader output paths

[maruthang]

PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix

What is the current behavior?

Assets processed by esbuild's file loader (e.g., SVGs imported via import svgUrl from './test.svg') do not get the deploy-url prefix applied. The publicPath option (derived from deployUrl) is passed to stylesheet bundling but not to the application code bundler's common options.

Issue Number: #32789

What is the new behavior?

Pass publicPath through to esbuild's common options in getEsBuildCommonOptions(), so file loader output paths are correctly prefixed with the deploy-url value.

No regression risk: Component stylesheets already explicitly delete publicPath before their own bundling (lines 72 and 127 in component-stylesheets.ts), preventing double-prefixing.

Does this PR introduce a breaking change?

• Yes
• No

[gemini-code-assist]

Code Review

This pull request updates the esbuild configuration to include the publicPath option, ensuring that file loader import URLs correctly prepend the deployment URL. A new test case was added to verify this behavior for file loaders. I have no feedback to provide.

[clydin]

Thank you for the contribution.

However, these changes affect the entire code bundling process and not just the file loaders. This would need to be handled in a fine-grained manner. But even that type of change may lead to breaking behavior for existing users. Further information is needed from the originating issue regarding a specific use case and reproduction before changes can made.

[maruthang]

Thanks for the feedback, @clydin. You're right — esbuild's publicPath also affects code-splitting chunk paths, not just file loader outputs.

A more targeted approach would be to modify the loader-import-attribute-plugin.ts to handle file loader imports specially — instead of delegating to esbuild's built-in file loader, the plugin could resolve the output path and prepend deploy-url itself. However, this adds complexity and I'd want to understand the issue reporter's specific use case better first.

I'll close this PR for now. If the issue reporter provides a reproduction, I'm happy to revisit with a fine-grained approach.