Fixes that the `ImportManager` was returning the `propertyName` instead of the `name` when there's an import with a conflicting identifier.
PR Close#49139
For the standalone migration we need to pass a couple of compiler flags which accidentally also overwrote the project's compiler options. These changes extend the options instead.
PR Close#48987
Fixes that the migration host was doing a basic falsy check if the content was read correctly which meant that a component with an empty template would be considered as having a missing template file.
Fixes#48846.
PR Close#48849
Makes the following minor improvements to our current schematic utilities:
* `closestNode` now takes a TS predicate function instead of a `SyntaxKind`. This allows it automatically infer the type of the match.
* `getImportSpecifier` now accepts a regex for the module name. This will be useful for some upcoming migrations.
* Splits the logic for creating the migration program options into a separate function so that it's easier to reuse.
* `createMigrationProgram` now returns the program directly, instead of a literal with some other information.
* `FakeReadFileFn` and `createMigrationCompilerHost` aren't exported anymore since they aren't used anywhere.
PR Close#48790
We dropped support for TypeScript 4.7 in version 15, but we had to keep around the runtime code, because of g3. Now that g3 is on 4.8, we can remove the additional code.
PR Close#48470
Fixes that imports weren't being combined in the `ImportManager` when multiple new imports are added for the same file. This wasn't a problem for previous schematics that used the manager, but it'll come up in some of the new ones.
Also moves the logic for writing new imports into `recordChanges`, instead of `addImportToSourceFile`.
PR Close#48620
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
The Angular CLI does not yet support schematics running as ESM. For
this reason we switch the schematics BUILD targets to explicitly
use ESM (as an exception in the repo).
PR Close#48521
Since Angular v15, the `RouterLink` contains the logic of the `RouterLinkWithHref` directive and now developers can always import and use the `RouterLink` directive when they need to add a `[routerLink]` in templates. This migration finds all imports and usages of the `RouterLinkWithHref` class and rewrites them to `RouterLink` instead.
```ts
import { RouterLinkWithHref } from '@angular/router';
@Component({
standalone: true,
template: `<a [routerLink]="'/abc'">`,
imports: [RouterLinkWithHref]
})
export class MyComponent {
@ViewChild(RouterLinkWithHref) aLink!: RouterLinkWithHref;
}
```
```ts
import { RouterLink } from '@angular/router';
@Component({
standalone: true,
template: `<a [routerLink]="'/abc'">`,
imports: [RouterLink]
})
export class MyComponent {
@ViewChild(RouterLink) aLink!: RouterLink;
}
```
PR Close#47599
Drops support for TypeScript older than 4.6 and removes some workarounds in the compiler.
BREAKING CHANGE:
TypeScript versions older than 4.6 are no longer supported.
PR Close#45394
Proactively replaces our usages of the deprecated `ts.create*` methods in favor of using `ts.factory.create*` so that we're not surprised when the TS removes them in the future. Also accounts for some cases where the signature had changed.
PR Close#45134
Cleans up some of the temporary workarounds that were necessary in order to land support for TypeScript 4.5 since they're no longer necessary.
PR Close#44477
Adds support for TypeScript 4.5. Includes the following changes:
* Bumping the package versions.
* Fixing a few calls to `createExportSpecifier` and `createImportSpecifier` that require an extra parameter.
* Adding some missing methods to the TS compiler hosts.
* Fixing an issue in the TS mocks for the ngcc tests where a regex was too agressive and was trying to match a path like `/node_modules/@typescript/lib-es5`.
* Accounting for type-only import specifiers when reporting DI errors (see #43620).
Fixes#43620.
PR Close#44164
The `NgComponentTemplateVisitor` helper was always referring back to the original source file on disk
rather than the virtual file in the migration. This meant that some template migrations could attempt
to modify the template multiple times resulting in invalid output.
As an example the `migration-v13-router-link-empty-expression` migrates the following template:
```
<div [routerLink]></div>
```
to
```
<div [routerLink]="[]"></div>
```
But if the template was referenced multiple times in the program, such as when the component was
referenced in the source and test entry-points, the migration would result in things like:
```
<div [routerLink]="[]"="[]"></div>
```
Fixes#44005.
PR Close#44013
Previously, when parsing code for templates to migrate, CRLF characters were converted to just LF.
This meant that the source-spans being used to overwrite the template strings in the original source code were out of sync with the positions identified in the parsed templates.
This commit fixes this by parsing the raw text of the template taken from the source code instead of processed string contents.
Fixes#44005
PR Close#44013
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler-cli` and its new secondary entry point `@angular/compiler-cli/private/migrations`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the dynamically loaded modules must now be passed to all locations that use values from the modules.
PR Close#43657
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
This reverts commit ab3de40ba3, which is
itself a revert of the original commit. Thus, this restores the changes
to schematics in support of ESM.
Now that g3 has a local modification for load_esm, we can restore this
functionality.
PR Close#43637
Currently, migrations and schematics must be in CommonJS format. However, framework packages will only be ESM from v13 and onward. To support this configuration, dynamic import expressions are now used to load `@angular/compiler`. Dynamic imports within Node.js allow the `@angular/core` migrations’ CommonJS code to load ESM code. Unfortunately, TypeScript will currently, unconditionally down-level dynamic import into a require call. `require` calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import. Due to the use of the dynamic import, a reference to the compiler module must now be passed to all locations that use values from the `@angular/compiler` package.
PR Close#43627
A base class that can be used to implement a Render3 Template AST visitor is now used throughout the `@angular/core` migrations. This class is used instead of the `NullVisitor` found within the `@angular/compiler` because the `NullVisitor` requires a deep import which is no longer supported with the ESM bundled packages as of v13. The `NullVisitor` is also fairly trivial in regards to its implementation and the new base class also provides additional helper methods for migration specific behavior. This removes all remaining deep imports of the `@angular/compiler` package from the `@angular/core` migrations while avoiding the need to modify the `@angular/compiler` package.
PR Close#43627
Most of the deep imports into the `@angular/compiler` package in the `@angular/core` migrations are for template AST types that are available as exports from the main entry point of the package (albeit under slightly different names). For the available main entry point exports, the deep imports have been transitioned to no longer use the deep import.
PR Close#43627
With this change we change the logic to locate the tsconfig files. The public API to locate, read and parse the workspace configuration should be use instead of the custom implemented logic.
The custom implemented logic depended on methods which have long been deprecated and are not removed in version 13 of the Angular CLI. This was not caught during development/UT because this repo is using outdated Angular Tooling packages.
This change also updates a number of spec files which previously creating an invalid Angular workspace configuration file.
Closes#43334
PR Close#43343
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
Adds a migration that casts the value of `ActivatedRouteSnapshot.fragment` to be non-nullable.
Also moves some code from the `AbstractControl.parent` migration so that it can be reused.
Relates to #37336.
PR Close#41092
Currently all of our migrations are set up to find the tsconfig paths within a project,
create a `Program` out of each and migrate the files inside of the `Program`. The
problem is that the `Program` can include files outside of the project and the CLI
APIs that we use to interact with the file system assume that all files are within
the project.
These changes consolidate the logic, that determines whether a file can be migrated,
in a single place and add an extra check to exclude files outside of the root.
Fixes#39778.
PR Close#39790
Adds a migration that finds all imports and calls to the deprecated `async` function from
`@angular/core/testing` and replaces them with `waitForAsync`.
These changes also move a bit of code out of the `Renderer2` migration so that it can be reused.
PR Close#39212
In #38227 the signatures of `navigateByUrl` and `createUrlTree` were updated to exclude unsupported
properties from their `extras` parameter. This migration looks for the relevant method calls that
pass in an `extras` parameter and drops the unsupported properties.
**Before:**
```
this._router.navigateByUrl('/', {skipLocationChange: false, fragment: 'foo'});
```
**After:**
```
this._router.navigateByUrl('/', {
/* Removed unsupported properties by Angular migration: fragment. */
skipLocationChange: false
});
```
These changes also move the method call detection logic out of the `Renderer2` migration and into
a common place so that it can be reused in other migrations.
PR Close#38825
The undecorated-classes-with-decorated-fields migration relies on
the type checker to resolve base classes of individual classes.
It could happen that resolved base classes have no value declaration.
e.g. if they are declared through an interface in the default types.
Currently the migration will throw in such situations because it assumes
that `ts.Symbol#valueDeclaration` is always present. This is not the
case, but we don't get good type-checking here due to a bug in the
TypeScript types. See:
https://github.com/microsoft/TypeScript/issues/24706.
Fixes#36522.
PR Close#36543
In rare cases a project with configured `rootDirs` that has imports to
non-existent identifiers could fail in the migration.
This happens because based on the application code, the migration could
end up trying to resolve the `ts.Symbol` of such non-existent
identifiers. This isn't a problem usually, but due to a upstream bug
in the TypeScript compiler, a runtime error is thrown.
This is because TypeScript is unable to compute a relative path from the
originating source file to the imported source file which _should_
provide the non-existent identifier. An issue for this has been reported
upstream: https://github.com/microsoft/TypeScript/issues/37731. The
issue only surfaces since our migrations don't provide an absolute base
path that is used for resolving the root directories.
To fix this, we ensure that we never use relative paths when parsing
tsconfig files. More details can be found in the TS issue.
Fixes#36346.
PR Close#36367
In version 10, undecorated base classes that use Angular features need
to be decorated explicitly with `@Directive()`. Additionally, derived
classes of abstract directives need to be decorated.
The migration already handles this for undecorated classes that are
not explicitly decorated, but since in V9, abstract directives can be
used, we also need to handle this for explicitly decorated abstract
directives. e.g.
```
@Directive()
export class Base {...}
// needs to be decorated by migration when updating from v9 to v10
export class Wrapped extends Base {}
@Component(...)
export class Cmp extends Wrapped {}
```
PR Close#35339
The import manager has been created for both the `missing-injectable`
and `undecorated-classes-with-di` migration. Both initial PRs brought
in the manager class, so the manager is duplicated in the schematics.
In order to reduce this duplication, and to expose the manager to other
schematics/migrations, we move it into the shared schematic utils.
PR Close#35339
Moves the `findBaseClassDeclarations` method into the shared
schematic utilities. This method will be useful for future
migrations, and for planned changes to the
`undecorated-classes-with-decorated-fields` migration.
PR Close#35339
Previously the calls to run the schematics were not being properly
or consistently awaited in the tests. While this currently does not
affect the tests' performance, this fix corrects the syntax and
adds stability for future changes.
PR Close#34364
The `renderer-to-renderer2` migration currently does not work
properly in v9 because the migration relies on the type checker
for detecting references to `Renderer` from `@angular/core`.
This is contradictory since the `Renderer` is no longer
exported in v9 `@angular/core`. In order to make sure that
the migration still works in v9, and that we can rely on the
type checker for the best possible detection, we take advantage
of module augmentation and in-memory add the `Renderer` export
to the `@angular/core` module.
PR Close#33571
Current we need to create and override certain compiler host methods in every schematic because schematics use a virtual fs. We this change we extract this logic to a common util.
PR Close#32827
Andrew Scott