feat(@angular/build): support custom resolution conditions with applications

[clydin]

When using the application build system, a new conditions option is now available that allows adding custom package resolution conditions that can adjust the resolution for conditional exports and imports. By default the module and production/development conditions will be present with the later dependent on the optimization option. If any custom conditions value is present including an empty array, none of these defaults will be present and must be manually included if needed. The following special conditions will always be present if their respective requirements are satisfied:

• es2015 (required by rxjs)
• es2020 (APF backwards compatibility)
• default
• import
• require
• node
• browser

For additional information regarding conditional exports/imports:
https://nodejs.org/api/packages.html#conditional-exports
https://nodejs.org/api/packages.html#subpath-imports

[alan-agius4]

The change itself LGTM, but what is the rational behind the change? Was there a feature request?

[jkrems]

I'd have a slight concern about making the dev/prod thing configurable. Some of our dependencies (or future versions of our libraries) may make the reasonable assumption that one or the other is always present. E.g. this may prevent us from pre-generating ngDevmode-stripped published libraries in the future? Speculative, admittedly. :)

[clydin]

I went with consistency with other tooling in the dev/prod condition area. esbuild/vite/etc. only keep "special" conditions if customization is present. This can be relevant for something like a staging build which may want optimization but with development code or vice versa.

[clydin]

This addition was also motivated by this issue wherein import conditions were a viable alternative to file replacements for development/production scenarios but not staging or similar cases.
#29546

[jkrems]

I will caution that "production" means "non-debug" or "release" and confusingly isn't related to the deployment stage. Using "staging" to replace dev/prod ("debug" and "release") is effectively undefined behavior. You might end up with a wild mix of debug- and non-debug code in your build.

For deployment target-specific dependent file replacements, I would recommend using something different like "deploy:staging" and "deploy:production" etc..

[clydin]

Additional documentation on some recommended best practices is definitely a good idea.
I think consistency with the wider ecosystem where appropriate is useful for options like this but deviation may be viable in certain cases.
The behavior can also always be adjusted in the pre-release phase for v20 based on usage and feedback.