FR: Add TS config option to disable "<some regex feature> is only available when targeting 'es2018' or later.".

[lauraharker]

Acknowledgement

• [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Search terms for existing issues

"regex", "regular expressions"

Problem

The Google TS build infrastructure runs the TypeScript compiler with a centrally defined target language = "ES2016" for edit-refresh & testing. For production, users can still target newer language versions, but for various reasons our edit-refresh setup is stuck on this older language version.

This means that with TS 5.5 we start seeing build errors like "This regular expression flag is only available when targeting 'es2018' or later.".

Our current workaround will be either using the RegExp constructor or adding a patch to our compiler fork.

Proposal

Add a TS config option to toggle whether these sorts of errors are emitted at all.

Use cases

I realize that Google infra's situation is unusual, so this might not be a generally useful proposal & understand if you don't support this.

However, some possibilities I could imagine for someone setting an older target language than necessary for the browsers they support might be:

• dependance on some semantics of the transpiled code, e.g. because of https://github.com/angular/angular/issues/31730
• some other part of the build toolchain not supporting newer syntax.

[DanielRosenwasser]

I think @ryancavanaugh and @rbuckton were of the opinion that users should add a // @ts-ignore - the new RegExp approach is probably a bit better. All in all, it's a bit unfortunate given your build situation. Do you have a sense of how many replacements you'd need here? Is there a point in time where you'd be able to swap to a high-enough target that it wouldn't be necessary?

[rbuckton]

I would say // @ts-ignore or // @ts-expect-error would be preferred over the RegExp constructor, is it indicates you've explicitly chosen to override the reported error. Using the RegExp just obfuscates potential errors or incompatibilities in a way that's harder to observe later.

[DanielRosenwasser]

Well...ts-expect-error can't be used because the build toggles into a valid version. And @ts-ignore has all the same issues around masking problems later on.

[jakebailey]

but for various reasons our edit-refresh setup is stuck on this older language version.

Out of curiosity, what are the "various reasons"?

[lauraharker]

Do you have a sense of how many replacements you'd need here? Is there a point in time where you'd be able to swap to a high-enough target that it wouldn't be necessary?

It's not a super high number, something less than 100.

Eventually we should be able to swap - we would like to use untranspiled output for testing for products that only ship to modern browsers, & have some work in progress for that, but are still blocked by Angular ZoneJS not being compatible with untranspiled async functions.

Out of curiosity, what are the "various reasons"?

Angular ZoneJS is the main one, since there's still a lot of Angular apps at Google. Then there's various historical architecture decisions around how the Google-internal https://bazel.build/ rules for web testing work, since a lot of this infra was written long enough ago when people just assumed users wanted ES5 out. We have some work in progress to clean this up. (I might be missing some reasons, I'm not an expert on https://bazel.build/)