`ng new --ssr=false` creates `angular.json` with `application` builder

[e-oz]

Command

ng new

Description

Right now ng new creates angular.json with @angular-devkit/build-angular:application in the builder field, even if SSR was not selected (or --ssr=false was applied).
It should set @angular-devkit/build-angular:browser-esbuild there and generate fields, related to this builder (right now it creates field browser).
Otherwise, the default config will lead to issues, described in #26304.

Minimal Reproduction

ng new example --ssr=false

[alan-agius4]

This is expected as the browser-esbuild is a compatibility builder that will be removed in the future.

We are looking into ways to mitigate the output path change.

[clydin]

This is intended behavior. The application builder is the preferred builder for all new projects and is recommended for all existing projects when viable based project specific requirements.

In regards to the output path, the output path option specifies the path in which build artifacts are placed following a successful build. Not all build artifacts are intended to be used by a browser nor are they all necessarily expected to be publicly exposed. This is especially true with SSR, but also regardless of the use of SSR. The consistent and well defined output artifact structure also provides a stronger guarantee for cloud providers, enabling more accurate and streamlined deployment in these cases. Deployment and/or staging steps post-build are an effective means to ensure that files intended to be accessible to browser clients, including potentially files not generated by the build system or that require post-processing, are placed in there intended and expected locations.

[e-oz]

@alan-agius4,

browser-esbuild is a compatibility builder that will be removed in the future

@dgp1130 says that it is not quite correct:
#26304 (comment) (in response to my comment).

Could you please clarify this?

[alan-agius4]

The browser-esbuiler is compatibility builder and is the easier way to migrate to use an esbuild based builder.

That said, using the application builder is preferred and eventually the long term goal is to remove the browser-esbuild based builder.

[ChrisCopelandSF]

The browser-esbuiler is compatibility builder and is the easier way to migrate to use an esbuild based builder.

That said, using the application builder is preferred and eventually the long term goal is to remove the browser-esbuild based builder.

According to the other issue that was raised, browser-esbuild is meant to be a de-facto solution for the fact that the recent, backwards-incompatible version change to the output path (adding browser and server directories) has been causing problems for people. If it's meant to be the tool for ensuring that the application is built as per the previous output path, but it's still planning on being removed in the future, what options are we going to have to going forward?

If people are already migrating their CI/CD pipelines and build options to use browser-esbuild because they don't want these directories (for any number of reasons) it baffles me that we're still in a position where the Angular team won't consider adding configuration options to remove these directories, and are also planning on removing the only tool that can do it?

[e-oz]

I completely agree with @ChrisCopelandSF

@clydin,

The consistent and well defined output artifact structure also provides a stronger guarantee for cloud providers, enabling more accurate and streamlined deployment in these cases.

I understand the idea, but in practice, it just requires one additional step on CI/build servers, that's it, no extra benefits.

@alan-agius4,

We are looking into ways to mitigate the output path change.

As an idea: add clientFilesFolder field and give it the default value 'browser', so users could re-define it to '' to get the desired behavior. Maybe serverFilesFolder as well (or some better name).

[e-oz]

I don't feel comfortable to discuss anything in closed issues, so I've opened a feature request: #26632

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