Option to do not override "target" and "useDefineForClassFields"

[e-oz]

Command

build, serve

Description

There are reasons why you've added this warning:

TypeScript compiler options "target" and "useDefineForClassFields" are set to "ES2022" and "false" respectively by the Angular CLI. To control ECMA version and features use the Browerslist configuration. For more information, see https://github.com/browserslist/browserslist

To control ECMA version and features use the Browerslist configuration

There is no way to define target and useDefineForClassFields in the Browerslist configuration.

Please provide some option to skip target and useDefineForClassFields overriding - some projects are not ready for ES2022 and they are too big to modify overnight (or in a few weeks) to be compatible with ES2022, although they are still compatible with Angular 15 itself.

Describe the solution you'd like

Just quick ideas:

--keep-target-value --keep-use-defined-value

and

"targets": {
    "build": {
      "executor": "@angular-devkit/build-angular:browser",
      "options": {
          "keepTargetValue": true,
          "keepUseDefinedValue": true
       }
   }
}

Describe alternatives you've considered

No response

[alan-agius4]

@e-oz, in the browserslist configuration you need to provide the list of browsers that the applications needs to support. This will control which ECMA features gets downlevelled.

Thw goal of this change is that users should not worry about setting the right ECMA version but rather set which browsers the application is meant to support.

[e-oz]

@alan-agius4 these things are orthogonal. I have a project that will run exclusively in the latest Chrome, so by this logic, I should use ES2022. But the code of this project is not ready for ES2022 (some fields are being used before they are defined in the constructor - it's just one example, the summary is "project is not ready for ES2022 and will not work properly"), so I use “target ES2021” in that project.

I would understand this enforcement for new projects when we call "ng init", but not for existing ones.

I'm not asking to roll back this feature (I do respect your ideas), just please make a way to opt out.

[alan-agius4]

ES2022 (some fields are being used before they are defined in the constructor - it's just one example, the summary is "project is not ready for ES2022 and will not work properly").

This should be solved through the useDefineForClassFieldsbeing set to false.

If you are experiencing issues please provide a minimal reproduction that we can take a look at as otherwise this issue is not actionable.

A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.

[e-oz]

I would understand this enforcement for new projects when we call "ng init", but not for existing ones.

A good way to make a minimal repro is to create a new app via ng new repro-app

That's an interesting combination :)

I don't think that feature requests need some "reproduction steps", so feel free to close it (or wait if someone else will vote for it).

[alan-agius4]

Adding those options is not desirable, as such I am going to closing this issue.

If you do experience an issue please open a new issue with a minimal reproduction.

[Splaktar]

Thw goal of this change is that users should worry about setting the right ECMA version but rather set which browsers the application is meant to support.

I think that this was meant to be?

The goal of this change is that users should not worry about setting the right ECMA version but rather set which browsers the application is meant to support.

[e-oz]

@Splaktar you can find more detailed info here: #23936

[alan-agius4]

@Splaktar, yeah thanks for pointed that out

[mgol]

FWIW, one good reason to be able to lock to a specific target version is that some features may technically be supported by a browser but not be optimized. For example, in one code base I maintain I had to lock the target below ES2018 as object spread in Chrome is so slow it was showing performance degradation in our app perf tests:
https://bugs.chromium.org/p/v8/issues/detail?id=10763

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