NG0204: Token InjectionToken X is missing a ɵprov definition after Angular 15 upgrade

[akoreh]

After updating to Angular 15, components with the following setup fail with NG0204: Token InjectionToken X is missing a ɵprov definition.

import {
  ChangeDetectionStrategy,
  Component,
  InjectionToken,
  Input,
} from '@angular/core';
import { UntilDestroy } from '@ngneat/until-destroy';

export const FAB_ITEM = new InjectionToken<any>('FAB_ITEM');

@UntilDestroy()
@Component({
  selector: 'aw-fab-item',
  templateUrl: 'fab-item.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
  providers: [{ provide: FAB_ITEM, useExisting: FabItemComponent }],
})
export class FabItemComponent {
  @Input() disabled = false;
}

The error dissapears and the component works after removing the UntilDestroy decorator.

[arturovt]

Could you please provide a minimal reproducible example?

[arturovt]

Closing as not reproducible. We have an integration app in this repository which is running with Angular 15.

Feel free to re-open the issue once you're able to provide a reproducible example.

[Wykks]

Got the same issue, same fix. No idea what's going on. I'm not able to reproduce it on stackblitz...

[anschm]

Got the same issue after migration to angular 15.

[anschm]

I saw that the repo was upgraded to angular 15. Could we get a new release? Maybe this fix the issue.

[arturovt]

Well, I could’ve published a new version but I’d want to double check to ensure this is related to a new version. Because that might be an unnecessary publish. I need a reproducible example gentlemen.

[anschm]

Could you publish a dev version so that I can check against my project?

[NetanelBasal]

I'm using Angular v15, and I don't have an issue. It'll be helpful if you can reproduce it.

[jogelin]

I have had something similar since the upgrade to Angular 15.

We have a use case where we want to get a MatFormFieldControl from a ControlValueAccessor component implementing the MatFormFieldControl that is injected using the Content Projection.

  @ContentChild(MatFormFieldControl, { static: true })
  private formFieldControl!: MatFormFieldControl<unknown>;

  ngOnInit(): void {
    this.matFormField._control = this.formFieldControl;

For MatFormFieldControl components that have the UntilDestroy() decorator, the this.formFieldControl is empty
When you remove the decorator, it works well again.

I'll try to provide a reproducible case today

[jogelin]

I was not able to reproduce our issue on a clean project TBH.

We are still investigating why it is failing by removing all codes around.

Even if I remove the code within the decorator it is failing.

Just the fact that we set the decorator has an impact on our @ContentChild reaction.

I think this is related to angular/angular#48276 but no idea what is the reason.

[jogelin]

Even trying that approach it fails:

function UntilDestroy(options = {}) {
  return (type: unknown) => {};
}

@UntilDestroy()
@Component({
...

So at least, this is not related to this library ;)

[arturovt]

To be honest I have issues in other libraries as well related to decorators. But it’s usually not a library issue but something related to the application.

Since I’ve seen already some issues related to decorators this means there actually has been some change in the TS compiler or Angular compiler that might affect it.

[mcaverick]

this typescript issue seems to be related

[jogelin]

It is indeed related to a modification of the way properties are set as you can see in the Typescript documentation. This new way is applied when your target is es2022.

Angular cli is aware of this as you can this in this code , it will set the correct value

The solution then is to set the target to es2021 then Angular Cli will hook the configurations and set es2022 and useDefineForClassFields to false

There is only one thing that we still don't understand is that if you set these values yourself to avoid the warning of Angular Cli, then it doesn't work. It seems typescript will read directly the file and just ignore useDefineForClassFields

Related tickets:

• Inconsistent parameter properties initialization order depending on the target syntax with useDefineForClassFields microsoft/TypeScript#45995
• useDefineForClassFields defaults to true when target is es2022, breaks decorators. microsoft/TypeScript#48814
• browser-esbuild target set to ES2022 and useDefineForClassFields false not working angular/angular-cli#24435

[arturovt]

Yeah, I haven't got my hands yet to going through the Angular 15 release completely. In other libraries this is being solved by playing around with useDefineForClassFields.

[arturovt]

Have to re-open the issue because I also experienced it in one of my apps (haven't met it earlier):

Error: NG0204: Token InjectionToken NgValueAccessor is missing a ɵprov definition.

Not sure how to fix it yet, will be looking for possible resolutions.

UPD: I ain't sure this is exactly related to this library.

[arturovt]

@jogelin I have experienced this issue with a control value accessor too. I have fixed it with the forwardRef.

Before:

provide: NG_VALUE_ACCESSOR,
useExisting: CosAutocompleteComponent

After:

provide: NG_VALUE_ACCESSOR,
useExisting: forwardRef(() => CosAutocompleteComponent),

Your thoughts?

P.S. I know it wasn't necessary to use forwardRef since Ivy has been released (because component definition appeared after the class itself, thus there has been no reason to "capture" the class reference).

[arturovt]

Ok, I just doubled checked my app and the issue wasn’t related to this library. Sorry for pinging anyone who’s subscribed to this issue.

[jogelin]

@jogelin I have experienced this issue with a control value accessor too. I have fixed it with the forwardRef.

Before:

provide: NG_VALUE_ACCESSOR,
useExisting: CosAutocompleteComponent

After:

provide: NG_VALUE_ACCESSOR,
useExisting: forwardRef(() => CosAutocompleteComponent),

Your thoughts?

P.S. I know it wasn't necessary to use forwardRef since Ivy has been released (because component definition appeared after the class itself, thus there has been no reason to "capture" the class reference).

Seems to work too :)

[sagrawal31]

I'm still able to reproduce the issue in Angular v15.2. Though, I'm not sure if I have to follow this approach #224 (comment)