iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/packages/core/schematics/migrations.json

50 lines
3.4 KiB
JSON
Raw Normal View History

feat(core): update schematic to migrate to explicit query timing (#28983) Introduces an update schematic for the "@angular/core" package that automatically migrates pre-V8 "ViewChild" and "ContentChild" queries to the new explicit timing syntax. This is not required yet, but with Ivy, queries will be "dynamic" by default. Therefore specifying an explicit query timing ensures that developers can smoothly migrate to Ivy (once it's the default). Read more about the explicit timing API here: https://github.com/angular/angular/pull/28810 PR Close #28983
2019-02-27 14:30:38 -05:00
{
"schematics": {
feat(core): add schematics to move deprecated DOCUMENT import (#29950) PR Close #29950
2019-04-17 00:06:06 -04:00
"migration-v8-move-document": {
fix(core): set migration schematic versions to valid semver versions (#32991) PR Close #32991
2019-10-03 20:49:02 -04:00
"version": "8.0.0-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "@DOCUMENT migration. Migrates DOCUMENT Injection token from platform-browser imports to common import.",
feat(core): add schematics to move deprecated DOCUMENT import (#29950) PR Close #29950
2019-04-17 00:06:06 -04:00
"factory": "./migrations/move-document/index"
},
feat(core): update schematic to migrate to explicit query timing (#28983) Introduces an update schematic for the "@angular/core" package that automatically migrates pre-V8 "ViewChild" and "ContentChild" queries to the new explicit timing syntax. This is not required yet, but with Ivy, queries will be "dynamic" by default. Therefore specifying an explicit query timing ensures that developers can smoothly migrate to Ivy (once it's the default). Read more about the explicit timing API here: https://github.com/angular/angular/pull/28810 PR Close #28983
2019-02-27 14:30:38 -05:00
"migration-v8-static-queries": {
fix(core): set migration schematic versions to valid semver versions (#32991) PR Close #32991
2019-10-03 20:49:02 -04:00
"version": "8.0.0-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "ViewChild and ContentChild to explicit query timing migration. In Angular version 8, developers need to explicitly specify the timing of ViewChild and ContentChild queries. Read more about this here: https://v8.angular.io/guide/static-query-migration",
feat(core): update schematic to migrate to explicit query timing (#28983) Introduces an update schematic for the "@angular/core" package that automatically migrates pre-V8 "ViewChild" and "ContentChild" queries to the new explicit timing syntax. This is not required yet, but with Ivy, queries will be "dynamic" by default. Therefore specifying an explicit query timing ensures that developers can smoothly migrate to Ivy (once it's the default). Read more about the explicit timing API here: https://github.com/angular/angular/pull/28810 PR Close #28983
2019-02-27 14:30:38 -05:00
"factory": "./migrations/static-queries/index"
feat(core): template-var-assignment update schematic (#29608) Introduces a new update schematic called "template-var-assignment" that is responsible for analyzing template files in order to warn developers if template variables are assigned to values. The schematic also comes with a driver for `tslint` so that the check can be used wtihin Google. PR Close #29608
2019-03-30 07:48:21 -04:00
},
"migration-v8-template-local-variables": {
fix(core): set migration schematic versions to valid semver versions (#32991) PR Close #32991
2019-10-03 20:49:02 -04:00
"version": "8.0.0-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "Template Variable Assignment migration. Warns developers if values are assigned to template variables.",
feat(core): template-var-assignment update schematic (#29608) Introduces a new update schematic called "template-var-assignment" that is responsible for analyzing template files in order to warn developers if template variables are assigned to values. The schematic also comes with a driver for `tslint` so that the check can be used wtihin Google. PR Close #29608
2019-03-30 07:48:21 -04:00
"factory": "./migrations/template-var-assignment/index"
feat(core): add automatic migration from Renderer to Renderer2 (#30936) Adds a schematic and tslint rule that automatically migrate the consumer from `Renderer` to `Renderer2`. Supports: * Renaming imports. * Renaming property and method argument types. * Casting to `Renderer`. * Mapping all of the methods from the `Renderer` to `Renderer2`. Note that some of the `Renderer` methods don't map cleanly between renderers. In these cases the migration adds a helper function at the bottom of the file which ensures that we generate valid code with the same return value as before. E.g. here's what the migration for `createText` looks like. Before: ``` class SomeComponent { createAndAddText() { const node = this._renderer.createText(this._element.nativeElement, 'hello'); node.textContent += ' world'; } } ``` After: ``` class SomeComponent { createAndAddText() { const node = __rendererCreateTextHelper(this._renderer, this._element.nativeElement, 'hello'); node.textContent += ' world'; } } function __rendererCreateTextHelper(renderer: any, parent: any, value: any) { const node = renderer.createText(value); if (parent) { renderer.appendChild(parent, node); } return node; } ``` This PR resolves FW-1344. PR Close #30936
2019-06-09 09:38:18 -04:00
},
"migration-v9-renderer-to-renderer2": {
fix(core): set migration schematic versions to valid semver versions (#32991) PR Close #32991
2019-10-03 20:49:02 -04:00
"version": "9.0.0-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "Renderer to Renderer2 migration. As of Angular 9, the Renderer class is no longer available. Renderer2 should be used instead. Read more about this here: https://v9.angular.io/guide/migration-renderer",
feat(core): add automatic migration from Renderer to Renderer2 (#30936) Adds a schematic and tslint rule that automatically migrate the consumer from `Renderer` to `Renderer2`. Supports: * Renaming imports. * Renaming property and method argument types. * Casting to `Renderer`. * Mapping all of the methods from the `Renderer` to `Renderer2`. Note that some of the `Renderer` methods don't map cleanly between renderers. In these cases the migration adds a helper function at the bottom of the file which ensures that we generate valid code with the same return value as before. E.g. here's what the migration for `createText` looks like. Before: ``` class SomeComponent { createAndAddText() { const node = this._renderer.createText(this._element.nativeElement, 'hello'); node.textContent += ' world'; } } ``` After: ``` class SomeComponent { createAndAddText() { const node = __rendererCreateTextHelper(this._renderer, this._element.nativeElement, 'hello'); node.textContent += ' world'; } } function __rendererCreateTextHelper(renderer: any, parent: any, value: any) { const node = renderer.createText(value); if (parent) { renderer.appendChild(parent, node); } return node; } ``` This PR resolves FW-1344. PR Close #30936
2019-06-09 09:38:18 -04:00
"factory": "./migrations/renderer-to-renderer2/index"
feat(core): add undecorated classes migration schematic (#31650) Introduces a new migration schematic that follows the given migration plan: https://hackmd.io/@alx/S1XKqMZeS. First case: The schematic detects decorated directives which inherit a constructor. The migration ensures that all base classes until the class with the explicit constructor are properly decorated with "@Directive()" or "@Component". In case one of these classes is not decorated, the schematic adds the abstract "@Directive()" decorator automatically. Second case: The schematic detects undecorated declarations and copies the inherited "@Directive()", "@Component" or "@Pipe" decorator to the undecorated derived class. This involves non-trivial import rewriting, identifier aliasing and AOT metadata serializing (as decorators are not always part of source files) PR Close #31650
2019-07-24 06:07:07 -04:00
},
"migration-v9-undecorated-classes-with-di": {
fix(core): set migration schematic versions to valid semver versions (#32991) PR Close #32991
2019-10-03 20:49:02 -04:00
"version": "9.0.0-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "Undecorated classes with DI migration. As of Angular 9, it is no longer supported to use Angular DI on a class that does not have an Angular decorator. Read more about this here: https://v9.angular.io/guide/migration-undecorated-classes",
feat(core): add undecorated classes migration schematic (#31650) Introduces a new migration schematic that follows the given migration plan: https://hackmd.io/@alx/S1XKqMZeS. First case: The schematic detects decorated directives which inherit a constructor. The migration ensures that all base classes until the class with the explicit constructor are properly decorated with "@Directive()" or "@Component". In case one of these classes is not decorated, the schematic adds the abstract "@Directive()" decorator automatically. Second case: The schematic detects undecorated declarations and copies the inherited "@Directive()", "@Component" or "@Pipe" decorator to the undecorated derived class. This involves non-trivial import rewriting, identifier aliasing and AOT metadata serializing (as decorators are not always part of source files) PR Close #31650
2019-07-24 06:07:07 -04:00
"factory": "./migrations/undecorated-classes-with-di/index"
feat(core): add undecorated classes with decorated fields schematic (#32130) Adds a schematic that adds a `Directive` decorator to undecorated classes that have fields that use Angular decorators. PR Close #32130
2019-08-15 05:40:53 -04:00
},
refactor: re-enable dynamic queries migration (#32992) Re-enables the dynamic queries migration, now that we have all of the necessary framework changes in place. Also moves the logic that identifies static queries out of the compiler and into the static queries migration, because that's the only place left that's using it. PR Close #32992
2019-10-04 03:38:51 -04:00
"migration-v9-dynamic-queries": {
"version": "9-beta",
refactor(core): update migrations descriptions (#33440) With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself. This is because now, the CLI will print the description defined in the `migrations.json` file. See: https://github.com/angular/angular-cli/pull/15951 PR Close #33440
2019-10-28 03:42:19 -04:00
"description": "Static flag migration. Removes the `static` flag from dynamic queries. As of Angular 9, the \"static\" flag defaults to false and is no longer required for your view and content queries. Read more about this here: https://v9.angular.io/guide/migration-dynamic-flag",
refactor: re-enable dynamic queries migration (#32992) Re-enables the dynamic queries migration, now that we have all of the necessary framework changes in place. Also moves the logic that identifies static queries out of the compiler and into the static queries migration, because that's the only place left that's using it. PR Close #32992
2019-10-04 03:38:51 -04:00
"factory": "./migrations/dynamic-queries/index"
feat(core): add postinstall ngcc migration (#32999) PR Close #32999
2019-10-04 09:20:03 -04:00
},
refactor: enable ng update migrations for v10 (#36921) Enables the `ng update` migrations for v10. Status for individual migrations: **undecorated-classes-with-di**. This migration dealt exlusively with inherited constructors and cases where a derived component was undecorated. In those cases, the migration added `@Directive()` or copied the inherited decorator to the derived class. We don't need to run this migration again because ngtsc throws if constructor is inherited from an undecorated class. Also ngtsc will throw if a NgModule references an undecorated class in the declarations. ***undecorated-classes-with-decorated-fields*** This migration exclusively deals with undecorated classes that use Angular features but are not decorated. Angular features include the use of lifecycle hooks or class fields with Angular decorators, such as `@Input()`. We want to re-run this migration in v10 as we will disable the compatibility code in ngtsc that detects such undecorated classes as `@Directive`. **module-with-providers**: This migration adds an explicit generic type to `ModuleWithProviders`. As of v10, the generic type is required, so we need to re-run the migration again. **renderer-to-renderer2**: We don't need to re-run that migration again as the renderer has been already removed in v9. **missing-injectable**: This migration is exclusively concerned with undecorated providers referenced in an `NgModule`. We should re-run that migration again as we don't have proper backsliding prevention for this yet. We can consider adding an error in ngtsc for v10, or v11. In either way, we should re-run the migration. **dynamic-queries**: We ran this one in v9 to reduce code complexity in projects. Instead of explicitly passing `static: false`, not passing any object literal has the same semantics. We don't need to re-run the migration again since there is no good way to prevent backsliding and we cannot always run this migration for future versions (as some apps might actually intentionally use the explicit `static: false` option). PR Close #36921
2020-05-04 15:58:42 -04:00
"migration-v10-missing-injectable": {
"version": "10.0.0-beta",
"description": "Missing @Injectable and incomplete provider definition migration. As of Angular 9, enforcement of @Injectable decorators for DI is a bit stricter and incomplete provider definitions behave differently. Read more about this here: https://v9.angular.io/guide/migration-injectable",
"factory": "./migrations/missing-injectable/index"
},
"migration-v10-module-with-providers": {
"version": "10.0.0-beta",
"description": "ModuleWithProviders migration. As of Angular 10, the ModuleWithProviders type requires a generic. This migration adds the generic where it is missing. Read more about this here: https://v10.angular.io/guide/migration-module-with-providers",
feat(core): add ModuleWithProviders generic type migration (#33217) Static methods that return a type of ModuleWithProviders currently do not have to specify a type because the generic falls back to any. This is problematic because the type of the actual module being returned is not present in the type information. Since Ivy uses d.ts files exclusively for downstream packages (rather than metadata.json files, for example), we no longer have the type of the actual module being created. For this reason, a generic type should be added for ModuleWithProviders that specifies the module type. This will be required for all users in v10, but will only be necessary for users of Ivy in v9. PR Close #33217
2019-10-17 02:40:36 -04:00
"factory": "./migrations/module-with-providers/index"
refactor: enable ng update migrations for v10 (#36921) Enables the `ng update` migrations for v10. Status for individual migrations: **undecorated-classes-with-di**. This migration dealt exlusively with inherited constructors and cases where a derived component was undecorated. In those cases, the migration added `@Directive()` or copied the inherited decorator to the derived class. We don't need to run this migration again because ngtsc throws if constructor is inherited from an undecorated class. Also ngtsc will throw if a NgModule references an undecorated class in the declarations. ***undecorated-classes-with-decorated-fields*** This migration exclusively deals with undecorated classes that use Angular features but are not decorated. Angular features include the use of lifecycle hooks or class fields with Angular decorators, such as `@Input()`. We want to re-run this migration in v10 as we will disable the compatibility code in ngtsc that detects such undecorated classes as `@Directive`. **module-with-providers**: This migration adds an explicit generic type to `ModuleWithProviders`. As of v10, the generic type is required, so we need to re-run the migration again. **renderer-to-renderer2**: We don't need to re-run that migration again as the renderer has been already removed in v9. **missing-injectable**: This migration is exclusively concerned with undecorated providers referenced in an `NgModule`. We should re-run that migration again as we don't have proper backsliding prevention for this yet. We can consider adding an error in ngtsc for v10, or v11. In either way, we should re-run the migration. **dynamic-queries**: We ran this one in v9 to reduce code complexity in projects. Instead of explicitly passing `static: false`, not passing any object literal has the same semantics. We don't need to re-run the migration again since there is no good way to prevent backsliding and we cannot always run this migration for future versions (as some apps might actually intentionally use the explicit `static: false` option). PR Close #36921
2020-05-04 15:58:42 -04:00
},
"migration-v10-undecorated-classes-with-decorated-fields": {
"version": "10.0.0-beta",
"description": "Undecorated classes with Angular features migration. In version 10, classes that use Angular features and do not have an Angular decorator are no longer supported. Read more about this here: https://v10.angular.io/guide/migration-undecorated-classes",
"factory": "./migrations/undecorated-classes-with-decorated-fields/index"
feat(core): update schematic to migrate to explicit query timing (#28983) Introduces an update schematic for the "@angular/core" package that automatically migrates pre-V8 "ViewChild" and "ContentChild" queries to the new explicit timing syntax. This is not required yet, but with Ivy, queries will be "dynamic" by default. Therefore specifying an explicit query timing ensures that developers can smoothly migrate to Ivy (once it's the default). Read more about the explicit timing API here: https://github.com/angular/angular/pull/28810 PR Close #28983
2019-02-27 14:30:38 -05:00
}
}
}