Currently as a part of the bootstrapping API migration we comment out the metadata of the root module and instruct users to re-run the module pruning step which can be cumbersome. These changes run the module pruning automatically.
Note that initially I tried to reuse the module pruning logic and to run it against the existing program, but it was problematic, because it was common to have conflicting changes for the same AST nodes.
PR Close#49030
The terser update included various changes, including changes to the
inline optimizations. Constants like for the bloom filter are no longer
inlined multiple times, but instead the constant is preserved and used
with a shortened/mangled name.
Note this also applies to other symbols like `SimpleChanges` too.
This means that such new variables now show up in the symbols goldens.
Concrete examples of inlined & no-longer inlined constants can be
seen in the PR description: https://github.com/angular/angular/pull/49000#issue-1576416106
PR Close#49000
Adds a function that allows for the import resolution for files to be customized in the standalone migration. Externally it's only use is to change `NgForOf` to `NgFor`, but we'll need it internally to deduplicate some Material modules.
Fixes#49006.
PR Close#49022
`setDisabledState` is supposed to be called whenever the disabled state of a control changes, including upon control creation. However, a longstanding bug caused the method to not fire when an *enabled* control was attached. This bug was fixed in v15.
This had a side effect: previously, it was possible to instantiate a reactive form control with `[attr.disabled]=true`, even though the the corresponding control was enabled in the model. (Note that the similar-looking property binding version `[disabled]=true` was always rejected, though.) This resulted in a mismatch between the model and the DOM. Now, because `setDisabledState` is always called, the value in the DOM will be immediately overwritten with the "correct" enabled value.
Users should instead disable the control directly in their model. (There are many ways to do this, such as using the `{value: 'foo', disabled: true}` constructor format, or immediately calling `FooControl.disable()` in `ngOnInit`.)
If this incompatibility is too breaking, you may also opt out using `FormsModule.withConfig` or `ReactiveFormsModule.withConfig` at the time you import it, via the `callSetDisabledState` option.
However, there is an exceptional case: radio buttons. Because Reactive Forms models the entire group of radio buttons as a single `FormControl`, there is no way to control the disabled state for individual radios, so they can no longer be configured as disabled.
In this PR, we have special cased radio buttons to ignore their first call to `setDisabledState` when in `callSetDisabledState: 'always'` mode. This preserves the old behavior.
PR Close#48864
We no longer need webdriver-manager as everything is tested
using Bazel with the Bazel-managed browsers and chrome/gecko drivers.
The drivers and browser binaries are managed as part of dev-infra's
shared browser/driver configuration in `bazel/browsers`.
PR Close#49009
Fixes that the migration was unnecessarily traversing top-level nodes. This was a large performance bottle-neck, because it involves a lot of language service lookups.
PR Close#49010
In some internal migrations the language service was throwing for some file reads which was crashing the migration. These changes add a `try/catch` to avoid interrupting it.
PR Close#49010
For the module pruning and bootstrap API migration steps we depend heavily upon the TypeScript `LanguageService` which ends up being slow on a large project. E.g. in some large internal projects single-file lookups were taking around 30s.
These changes introduce a wrapper around the `LanguageService` that we can use to trick it into not traversing the entire project every time.
PR Close#49010
We're using Node's `path` utilities to remap existing imports and create new ones which can yield paths with forward slash separators.
These changes add some logic to ensure that we only generate forward slashes.
PR Close#48993
Normally having a standalone declaration in the `imports` array is an error and something we handle in the conversion to standalone, but tests can end up in this situation, because apps may have separate tsconfigs for the main app and for tests.
These changes make it so that we move any incorrectly-defined standalone declarations, even if they aren't part of the current migration.
PR Close#48987
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 we were copying all expressions in the `imports` array of the test to the `imports` of the component, including any potential `ModuleWithProviders`.
Fixes#48971.
PR Close#48987
The first step of the migration updates the tests of the component being migrated, however it also skips any bootstraped declarations. We get back to the these declarations when converting to the standalone bootstrapping APIs, but we weren't updating their tests.
These changes rework some of the logic so that we migrate any remaining tests as a part of the final step.
Relates to #48944.
PR Close#48987
Currently the standalone migration is set up to skip any modules that have a `bootstrap` array with at least one element. This ends up being misleading for small apps who have everything in the root module.
These changes add some logic to only skip the root component.
Fixes#48944.
PR Close#48987
v16 will have a breaking change to the way `UrlTree`s are constructed.
This change is actually a bug fix that makes `UrlTree` creation correct
in more scenarios (see #48508). However, this can affect applications that are
relying on the current incorrect behavior. This commit adds a dev mode
warning when the target of a navigation will change once #48508 is
submitted.
PR Close#48688
In #48898 the `isForwardRef` flag was added to indicate whether a reference should be wrapped in a `forwardRef`. This logic assumed that the node can't be referring to another node within the same file, however from testing it looks like that's not actually the case, because we hit the same code path when an external import to the same symbol exists already.
PR Close#48988
Fixed a typo and updated the hyphenation in a couple of words to keep consistency across schematics docs style. Assuming beginners reading docs, I also added the property called
public showGreeting = true;
This is because it is available in the examples `.HTML` `*ngIf` directive snippets without being present in the `.ts` class properties declarations. also this removes potential inference that this absence is a result of the standalone migration schematics work.
PR Close#48961
Internally we'll need to remap some imports to generate better import statements. These changes add an API that we can use to do the remapping.
PR Close#48974
Adds some logic to prefer non-Angular-internal modules when generating imports. This allows us to generate better code for some cases like the `ɵInternalFormsSharedModule` in Forms.
Also adds some logic to prefer symbols that are already in the same file.
Fixes#48942.
PR Close#48958
Fixes that the standalone migration was throwing the "Could not find any paths to migrate..." error on a per-tsconfig-basis, preventing the migration from running on any configs that might occur further down in the project.
These changes move the error to after all the configs have been checked.
PR Close#48958
Add a new loaderParams attribute, which can be used to send arbitrary data to a custom loader, allowing for greater control of image CDN features.
PR Close#48907
Previously if the standalone migration saw a `RouterModule.forRoot` with a config object, it wouldn't migrate it. These changes add some logic that convert the config object to a set of features from the new router API.
PR Close#48935
In the `PotentialImport` we indicate if it's in the same file by not setting a `moduleSpecifier`, but if that's the case, the imported symbol might need to be wrapped in a `forwardRef` to avoid generating an error. These changes expose this information so the various tools can take advantage of it.
PR Close#48898
This commit updates the docs of the functional guards and resolvers to improve the migration
experience when moving away from class-based equivalents.
PR Close#48873
`strictStyling` was an option provided by Polymer but it's not needed by Angular. This commit removes the dead code and updates related comments.
PR Close#48824
Some 1p module which uses the method TscPlugin.wrapHost requires to import this type to make its internal class definitions compatible with this type.
PR Close#48874
Currently the migration is set up to assume that any elements that exist in a `declarations` array will be converted to standalone and copied into the `imports` array, however that might be incorrect for some special cases like the root component.
These changes rework the declaration merging logic so that they take all the declarations being migrated into account.
PR Close#48882
Fixes that running the standalone migration with `--defaults` was throwing an error, because all the properties were specified as required. We don't need to set them as required, because they have default values.
Fixes#48845.
PR Close#48921
Fixes that we were changing the testing modules that have no `declarations` unnecessarily, resulting in more formatting changes that users would have to clean up.
PR Close#48921
Jasmine has deprecated the `expectationFailOutput` argument and replaced it by the `withContext()` method
Also removing all references to #24571 from the forms unit tests as the non null assertions are fine in the context.
PR Close#48894
Previously, the state `script` was always appended as the last item in the `body` tag. This can result in the state not being available when the Angular application is bootstrap.
A workaround for this was to delay the bootstrapping of the application until by using the `DOMContentLoaded` event listener.
```ts
const bootstrap = () => platformBrowserDynamic().bootstrapModule(AppModule);
document.addEventListener('DOMContentLoaded', bootstrap);
```
With this change the above workaround is no longer necessary as the state `script` tag is now added prior of any other `script` which guarantees that the state is present prior of the Angular application is bootstrapped.
PR Close#48868
Angular Robot