respect wepack export condition for importing

[spike-rabbit]

Command

build, extract-i18n, serve, test

Description

The root problem I am trying to solve is the different import behavior of esbuild and webpack for url resources like described here ( #24470 ).

We have a npm package shipping company fonts and scss file to import them.

I know that there are other possibilities, but I also discovered that we could have different entrypoints for webpack and esbuild
when using conditions in the package.json as described here: https://webpack.js.org/guides/package-exports/#conditions-preprocessor-and-runtimes.

This was leading me to this package.json

  "exports": {
    "./styles/*": {
      "webpack": {
        "sass": "./dist/styles/webpack/*.scss",
        "less": "./dist/styles/webpack/*.less",
        "style": "./dist/styles/webpack/*.css"
      },
      "sass": "./dist/styles/*.scss",
      "less": "./dist/styles/*.less",
      "style": "./dist/styles/*.css"
    },
    "./*": "./dist/fonts/*"
  }

The only problem here is, that this does not work. Webpack is loading the normal sass styles.

Describe the solution you'd like

It would be really cool if the webpack condition is matched.

Describe alternatives you've considered

We could offer a scss variable so that consumers can override the font path or just casually export the file. This still does not solve the problem when using esbuild and the karma runner but at least they could do something.

I am not sure how much effort it is fixing this, but in case you just need to add webpack here: https://github.com/angular/angular-cli/blob/main/packages/angular_devkit/build_angular/src/tools/webpack/configs/styles.ts#L382 it would be really cool if you could do it.

[dgp1130]

We do expect some amount of breaking changes between browser and application builders, so supporting library authors exporting different files for the different build systems does make some amount of sense. I wish we didn't have to do that, but for library authors to support both it might be necessary.

Ideally we'd just have the same behavior for both build systems, and maybe we can improve the story for #24470, but even if we do, it feels like there will be other subtle breaking changes which can cause pain for library authors. If we're expecting some amount of those breaking changes with no common format that works for both, then we might need something like this to support libraries trying to be compatible with both build systems.

@clydin, what do you think about this?

[angular-robot]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.