ESBuild builders inconsistent in importing CSS vs SCSS if both files exist

[bgotink]

Command

build, serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

When resolving import paths, sass doesn't require the extension to be present. The esbuild builders (application and browser-esbuild) handle these extensions inconsistently, sometimes favouring CSS over Scss if both files exist, and sometimes the other way around.

Minimal Reproduction

1. Clone https://github.com/bgotink/angular-repro-esbuild-scss-resolution
2. npm ci
3. npm exec ng build
4. cat dist/test/browser/styles-*.css

Note the content of the CSS file is

:root{--file: resolve-test/test.css}:root{--file: local-test.scss}

indicating that for local files, .scss is favoured over .css, while for files imported from packages .css is favoured over .scss.

The webpack builder favours .scss over .css in both scenarios.

Exception or Error

No response

Your Environment

_                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 17.2.0
Node: 18.14.0
Package Manager: npm 9.3.1
OS: darwin arm64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1702.0
@angular-devkit/build-angular   17.2.0
@angular-devkit/core            17.2.0
@angular-devkit/schematics      17.2.0
@angular/cli                    17.2.0
@schematics/angular             17.2.0
rxjs                            7.8.1
typescript                      5.3.3
zone.js                         0.14.4

Anything else relevant?

No response

[clydin]

Unfortunately, within Sass files there is no defined behavior for deep imports of bare package specifiers. Packages should ideally specify exports fields with the preferred ordering of usage for consumers. However, the newly introduced pkg: scope does have an algorithm defined within its implementation. This is not yet available for use within the Angular CLI but implementation is being evaluated. Also of note is that even though the new scope supports deep imports with the Sass discovery logic, it still recommends using the exports fields where possible. For more details please see: https://sass-lang.com/blog/announcing-pkg-importers/

[bgotink]

While there was indeed no specification specifically for importing from packages before the recent introduction of pkg:, the sass module spec clearly states that .sass and .scss have preference over .css when resolving the extension of an extensionless import (https://github.com/sass/sass/blob/main/spec/modules.md#resolving-a-file-url-for-extensions).

[clydin]

That's for file URLs though. The concept of resolving a node module package was not part of the spec and technically the package specifier itself should be treat as a relative file but that would be highly prohibitive from a usability perspective since a fixed path to and then inside the node modules directory would need to be used. This could be done now within an application and the behavior would be as expected based on the spec. However, bundlers, as a result of the awkwardness of such a solution, unofficially added behavior beyond the specification to allow JS like imports and in some cases inconsistently (tilde, root relative, partial discovery, exports vs deep import behavior, etc. can vary significantly). The pkg scope is an attempt create a consistent and unified process to handle package resolution.

[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.}