New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@angular/core update schematic v9 to v10 adds odd todo comments in a correct-looking file #37726
Comments
|
More details I noticed it added these todos to 2 // TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
@Pipe({
name: 'nxTimeAgo',
pure: false
})
export class NxTimeAgoPipe implements PipeTransform, OnDestroy {and // TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
// TODO: Add Angular decorator.
@Injectable({
providedIn: 'root'
})
export class NavigationService implements OnDestroyThis one is not affected @Pipe({
name: 'nxNumber',
pure: false
})
export class NumberPipe implements PipeTransform {All other pure pipes don't have todo comments I first thought it is related to A previous schematic also throws a warning that is related to this issue time-ago.module.ts import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';
import { TimeagoClock, TimeagoCustomFormatter, TimeagoDefaultClock, TimeagoFormatter, TimeagoIntl, TimeagoModule, TimeagoModuleConfig } from 'ngx-timeago';
import { CustomTimeAgoIntl } from './custom-time-ago-intl';
import { NxTimeAgoPipe } from './time-ago.pipe';
@NgModule({
imports: [
CommonModule,
TimeagoModule
],
declarations: [
NxTimeAgoPipe
],
exports: [
NxTimeAgoPipe
]
})
export class TimeAgoPipeModule {
static forRoot(config: TimeagoModuleConfig = {}) {
return {
ngModule: TimeAgoPipeModule,
imports: [
TimeagoModule.forRoot()
],
providers: [
config.intl || { provide: TimeagoIntl, useClass: CustomTimeAgoIntl },
config.clock || { provide: TimeagoClock, useClass: TimeagoDefaultClock },
config.formatter || { provide: TimeagoFormatter, useClass: TimeagoCustomFormatter }
]
};
}
}Full error message |
|
Also noted that angular adds the same error to services that implement |
|
I noticed the same. It added so many TODO comments to a guard I have: And for a service I have, it added |
As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Also while being at it, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726.
As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726.
As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726.
|
I had something similar but completely different ;) @Directive() // it added this
export abstract class AbstractComponent implements OnInit, OnDestroy {
|
|
@snebjorn It seems that this is the expected behavior. Your class might be suffixed with As of version 9, it's required to explicitly decorate such classes. Just using
It will break though when you use |
None critical. But it's confusing when looking through the code as it looks like a derived Component is inheriting from a Directive. So unless you're aware of this requirement then it looks like an error. I also had to disable my linting rule |
As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726.
…#37732) As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes #37726. PR Close #37732
…angular#37732) As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726. PR Close angular#37732
- ran update schematics to v10 and fixed tests - due to new TS version introduced with Angular v10 upgrade, e2e tests needed modifications to compile properly, and a previous transitive dependency needed to be explicitly added - Angular CLI added comments to higlight manual actions needed after migration, but no action was needed (see angular/angular#37726) - correctly updated Angular dependencies in lib package, moving tslib from peerDependencies to dependencies as suggested by build warning
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…angular#37732) As of v10, the `undecorated-classes-with-decorated-fields` migration generally deals with undecorated classes using Angular features. We intended to run this migation as part of v10 again as undecorated classes with Angular features are no longer supported in planned v11. The migration currently behaves incorrectly in some cases where an `@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy` lifecycle hook. We incorrectly add a TODO for those classes. This commit fixes that. Additionally, this change makes the migration more robust to not migrate a class if it inherits from a component, pipe injectable or non-abstract directive. We previously did not need this as the undecorated-classes-with-di migration ran before, but this is no longer the case. Last, this commit fixes an issue where multiple TODO's could be added. This happens when multiple Angular CLI build targets have an overlap in source files. Multiple programs then capture the same source file, causing the migration to detect an undecorated class multiple times (i.e. adding a TODO twice). Fixes angular#37726. PR Close angular#37732
Affected Package
The issue is caused by package @angular/coreDescription
ng update @angular/corefrom v9 to v10 adds multiple comments that tell me I need to change something which I did not expectThe code looks like this
It already has a decorator. I assume this is a bug and I can't do anything to satisfy ng update @angular/core ?
I'm not sure if the above example alone is enough for a reproduction on your side. Let me know if you need more!
The text was updated successfully, but these errors were encountered: