Sass files not correctly compiled with new ESBuild

[AStoker]

Which @angular/* package(s) are the source of the bug?

compiler-cli

Is this a regression?

Yes

Description

When Angular now compiles with the ESBuild option (using Angular 16), sass files no longer import external resources (using the url) correctly.
Essentially, behavior is such that if a Sass file (let's call it module A) imports another sass file (let's call it module B), and module B lives in a different directory than Module A, and Module B uses a url to point to a relative file (like a font file), when Sass compiles everything into a single Sass file, the url that's used from Module B remains the same (which is relative to the original Module B location), resulting in errors around resolving file locations (because the compiled file doesn't have the same file location as the original).
Original behavior didn't care about this, and the compiled output correctly brought linked files up and changed the url paths.
While ESBuild is called a "drop-in" replacement, this needs to be resolved.

Please provide a link to a minimal reproduction of the bug

https://github.com/AStoker/esbuild-font-import

Please provide the exception or error you saw

X [ERROR] Could not resolve "../webfonts/ShadowsIntoLight-Regular.ttf" [plugin angular-css-resource]

    src/styles.scss:6:11:
      6 │   src: url("../webfonts/ShadowsIntoLight-Regular.ttf") format("true...
        ╵            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 16.0.1
Node: 18.15.0
Package Manager: yarn 1.22.19
OS: win32 x64

Angular: 16.0.1
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1600.1
@angular-devkit/build-angular   16.0.1
@angular-devkit/core            16.0.1
@angular-devkit/schematics      16.0.1
@schematics/angular             16.0.1
rxjs                            7.8.1
typescript                      5.0.4

Anything else?

No response

[clydin]

Please see the following comment in a related issue: #24470 (comment)

In the specific example within the reproduction, the following code from src/app/foo/blar/imports.scss will also build (and correctly resolve the imported file's relative path):

@font-face {
  font-family: 'Shadows into light';
  font-style: normal;
  font-weight: 400;
  src: url('../webfonts/ShadowsIntoLight-Regular.ttf') format('truetype');
}

[AStoker]

Not clear about what you're saying. Are you saying that the repo builds fine for you? With the es-build option enabled? It definitely isn't on my end. If you were to just compile that specific file, sure, it would work. But the fact that it's being imported from a file that exists in a different directory, and that file is being imported from the root, is the reason the url's are all messed up.

But more than that, looking at that linked comment, it's not an acceptable solution unfortunately. First, not every SASS library has a variable that can be set to change links to things like font files. And secondly, if you are able to set the path for those font files, they don't get hoisted, and the resulting SCSS file simply tries to reference files directly inside the node_modules folder, which isn't (and shouldn't) be deployed.

[clydin]

If the code provided in the comment above is used in place of the current file's content, the application should build successfully and the referenced font file should be resolved and provided in the output.
Relative paths directly specified within the Sass files will be rebased based on the imported location.

The reproduction in its original form happens to work with Webpack due to some expensive build time processing and Webpack-specific loader source map manipulation (even when source maps are disabled). The reproduction also does not work with other bundlers such as Vite.
With either of the two options provided in the referenced comment, the font-awesome package's font files should be processed by the build system and available in the output as expected. With the bare specifier being the preferred option as it is only requires a single statement and avoids expensive and otherwise unneeded Sass preprocessing.
If neither of the options work within a build for your project, please let us know.

[alan-agius4]

Closing as per above explanation. If the problem persists please file a new issue.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}