support for providing esbuild options

[DRiFTy17]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

Regarding the new experimental @angular-devkit/build-angular:browser-esbuild builder, it would be great if you could expose a way to set esbuild options via configuration, specifically the external option is what I'm looking for at the moment to ensure externalized code (consumed/shared at runtime via ESM from a CDN) is not included in the Angular bundle (we want to use bare module specifiers and import maps).

For context, we are using @angular/elements combined with the new esbuild builder to share a custom element across applications, and consume shared ESM dependencies in both the application and custom element. We use typings from an npm package locally for the bare module specifier, but importmap at runtime to route it to the CDN.

I know this builder is experimental still, but I figured you would be interested in understanding how we're attempting to use it.

Describe the solution you'd like

I would expect to provide these options via angular.json. Something along the lines of an esbuildOptions property that will get passed directly down to esbuild.

Describe alternatives you've considered

I've modified the node_modules/@angular-devkit/build-angular/src/builders/browser-esbuild/esbuild.js file locally for testing purposes to get by for now which works, but otherwise I'll need to fork this repo to produce my own build that supports this until it's implemented in the main package. If this isn't something on your radar any time soon please let me know and I could create a PR when it comes time for us needing to put more priority on this.

Also, if you know of an alternative workaround to pass the config for the short term please let me know!

[alan-agius4]

Hi @DRiFTy17,

Thanks for trying out the new experimental esbuild builder.

In general we prefer not to expose options from the underlying tools. As an example right now we don't expose any of the Webpack options. The reason for this is that if we did, it would make migrating to different tool harder and in some cases breaking to the end-users. While if we kept the tools used as an implementation detail the transition can be done seamlessly.

That being said, I think that an external option can be either to both of our browsers builders as it can be useful in cases when Angular Elements is used.

Let's me label this so we discuss this in our next team meeting.

[nitedani]

I'm against the idea of taking away control from the developers and building a closed ecosystem. I would like every setting to be exposed. And when I break something, that's on me. At the moment I'm working on an angular universal project, using multiple custom webpack configuration files. For example, on the server build I don't bundle the dependencies that are only used client-side. If that was not possible, I would need to do ugly workarounds in the universal code. Even better, a straightforward and documented way would be best for building the angular application, without the angular-cli. Instead of building internal tools to be used exclusively by the angular-cli, tools, like the new esbuild pipeline, should be built and documented for developers to integrate into their existing build systems. Developers then would be able to use any tool and configuration they prefer to build the angular application.

[alan-agius4]

We discussed this during our triage meeting yesterday, and we agreed that adding an external option would be beneficial and we will be looking into added this feature soon.

On the other hand, exposing all of the options is not something that we will consider. This opens up the API surface and room for errors and undefined behaviour way too much. It would also not be too different from using the preferred tool/bundler directly and configure it as you wish, which you are free to do so, but this path is not supported by the Angular team. Similarly, while the Angular CLI is extendable through 3rd party builders, extending the bundler configuration or issues caused by this are also not supported by the Angular team.

That said, if you feel that there is missing functionally in one of the builders please do open a feature request.