This commit introduces a number of changes to the server bootstrapping process to make it more robust and less error-prone, especially for concurrent requests.
Previously, the server rendering process relied on a module-level global platform injector. This could lead to issues in server-side rendering environments where multiple requests are processed concurrently, as they could inadvertently share or overwrite the global injector state.
The new approach introduces a `BootstrapContext` that is passed to the `bootstrapApplication` function. This context provides a platform reference that is scoped to the individual request, ensuring that each server-side render has an isolated platform injector. This prevents state leakage between concurrent requests and makes the overall process more reliable.
BREAKING CHANGE:
The server-side bootstrapping process has been changed to eliminate the reliance on a global platform injector.
Before:
```ts
const bootstrap = () => bootstrapApplication(AppComponent, config);
```
After:
```ts
const bootstrap = (context: BootstrapContext) =>
bootstrapApplication(AppComponent, config, context);
```
A schematic is provided to automatically update `main.server.ts` files to pass the `BootstrapContext` to the `bootstrapApplication` call.
In addition, `getPlatform()` and `destroyPlatform()` will now return `null` and be a no-op respectively when running in a server environment.
(cherry picked from commit 8bf80c9d2314b4f2bcf3df83ae01552a6fc49834)
PR Close#63640
While having both `HttpClientModule` & `HttpClientTestingModule` serves no real purpose (`HttpClientTestingModule` imports `HttpClientModule`), some code bases can have those 2 together and the migration can be quite breaking.
fixes#58536
PR Close#58777
Currently during the module pruning stage of the standalone migration we assume that any leftover modules which only have `imports` and `exports` can safely be removed. That can be incorrect for the cases where some parts of the app were converted to standalone outside of the migration.
These changes update the logic so that such modules are replaced with the `exports` which are used within the specific component.
Fixes#51420.
PR Close#57684
Updates the migration so that it passes the type as a generic in the case of `@Inject(SOME_TOKEN) foo: SomeType`. This is done for two reasons:
1. It's a fairly common pattern and it ensures that the code can still be compiled.
2. It avoids leaving behind unused imports.
PR Close#57389
Makes it so the inject migration preserves the optional token when declaring a parameter. This came up in some testing as something that can be potentially breaking for classes that implement interfaces.
PR Close#57367
The `inject` migration can leave some unused imports behind when it removes decorators like `@Inject`. These changes add some logic to remove them.
PR Close#57179
Updates the inject migration to unwrap the `forwardRef` call in cases like `constructor(@Inject(forwardRef(() => Foo)) foo: Foo);`, because the `forwardRef` will type the initializer to `any` and it shouldn't be necessary.
PR Close#57127
This can up in Material where we had a `constructor(@Optiona() foo: Foo | null)` which ended up producing incorrect code, because the union type was preserved.
These changes resolve the issue by picking out the first non-literal type from the union for the `inject` call.
PR Close#57127
Currently if an injected type has type arguments, we copy it over together with the type arguments to inject, because `inject()` isn't able to infer the generic properly otherwise. E.g. if there's `constructor(el: ElementRef<HTMLElement>)` we produce `inject<ElementRef<HTMLElement>>(ElementRef<HTMLElement>);`.
These changes drop the generics from the `inject()` parameter since we're overwriting the type anyway. The example from above would become `inject<ElementRef<HTMLElement>>(ElementRef);`.
PR Close#57127
Adds the new `ng generate @angular/core:inject-migration` schematic that will convert existing code from constructor-based injection to injection using the `inject` function. The migration also has a few options that should help reduce compilation errors.
This migration is slightly different than our usual ones in that it may have to update entire class or constructor declarations. We don't go through the `ts.factory.update*` APIs for this, because it can cause the entire declaration to be re-formatted. Instead, this migration tries to insert strings in a way that won't affect the user's formatting.
PR Close#57056
This fixes the case that common module is removed on a second run of the migration. We were not looking at block parameters for common module usage.
PR Close#56968
Before this commit, the migration was removing the `AfterRenderPhase` enum from the imports but not the comma, resulting in invalid code:
ts
```
import { , Directive, afterRender } from '@angular/core';
```
This commit fixes this by using `updateNamedImports` and `replaceNode` instead of `removeNode`.
After:
ts
```
import { Directive, afterRender } from '@angular/core';
```
PR Close#56524
Adds an `ng update` migration to move users from using the phase flag
with `afterRender` / `afterNextRender` to passing a spec object instead.
PR Close#55648
empty ngSwitchCase generate `case ()` which isn't valid syntax therefore adding quotes will help prevent us migrate empty case if no condition was provided
fix angular#56030
PR Close#56105
The migration was breaking tests with test modules that imported `HttpClientTestingModule`,
as it removed the JS imports without migrating the module imports.
The migration now handles the case where `HttpClientTestingModule` is used in test modules,
by replacing the module import with the `provideHttpClient` and `provideHttpClientTesting` providers.
Before:
```ts
import { HttpClientTestingModule } from '@angular/common/http/testing';
@NgModule({
declarations: [AppComponent],
imports: [HttpClientTestingModule],
})
export class TestModule {}
```
After:
```ts
import { provideHttpClientTesting } from '@angular/common/http/testing';
import { provideHttpClient, withInterceptorsFromDi } from '@angular/common/http';
@NgModule({
declarations: [AppComponent],
imports: [],
providers: [provideHttpClient(withInterceptorsFromDi()), provideHttpClientTesting()]
})
export class TestModule {}
```
PR Close#55803
The `HttpClientModule` migration was dropping the existing properties other than imports and providers when updating an `@NgModule`, `@Component` or `configureTestingModule`.
PR Close#55777
This commit handles two cases that were breaking applications when using the new migration:
- tests using `HttpClientModule` in `TestBed.configureTestingModule` were broken as the import was removed, but the module is still present in the test configuration. It now properly adds `provideHttpClient(withInterceptorsFromDi())` and related imports to the test.
- tests using `HttpClientTestingModule` were migrated to use `provideHttpClient(withInterceptorsFromDi())` but the necessary imports were not added. They are now added by the migration.
PR Close#55640
Fixes several issues with the `HttpClient` migration that showed up after I tried updating the Material docs site to the latest v18 release. Includes:
* The migration was assuming that all Angular decorators have at least one argument. This led to a null pointer error that broke the v18 update process when I was testing it.
* The migration incorrectly reimplemented the detection of classes with Angular decorators. This can cause code to be migrated incorrectly and doesn't handle cases like import aliases. I've switched it to use the existing tooling for detecting decorated classes.
* The migration was trying to migrate directives, even though they don't support the `imports` field.
* The migration was detecting `TestBed.configureTestingModule` calls using a raw string match which is very fragile and can be broken by the user's formatting.
* There were syntax errors in the unit tests.
* There were type checking errors in the unit tests, for example none of them were importing the Angular decorators that they were migrating.
There's more room for improvement, but this should resolve the most glaring issues without having to rewrite too much.
PR Close#55557
This migration will allow developers to migrate the deprecated `HttpClientModule`, `HttpClientJsonpModule` & `HttpClientXsrfModule` to their respective provider functions.
PR Close#54020
This commit removes of migrations introduced in version 17, along with the relocation of a migration from 17.3 to version 18. This ensures that this is ran for users who may have updated from one minor to another without executing `ng update`
PR Close#55391
The control flow migration was using a couple of Greek letters as placeholders. This ended up conflicting with templates authored in Greek.
These changes use a more obscure placeholder to make conflicts less likely. It also moves the placeholder generation to a centralized function so it's easier to make changes if we decide to update the pattern again.
Fixes#55085.
PR Close#55113
Fixes that the control flow migration was throwing an error if the `imports` of a component are initialized to an identifier.
Fixes#55080.
PR Close#55081
As a part of #54154, an old parser behavior came up where two-way bindings were parsed by appending `= $event` to the event side. This was problematic, because it allowed some non-writable expressions to be passed into two-way bindings.
These changes introduce a migration that will change the two-way bindings into two separate input/output bindings that represent the old behavior so that in a future version we can throw a parser error for the invalid expressions.
```ts
// Before
@Component({
template: `<input [(ngModel)]="a && b"/>`
})
export class MyComp {}
// After
@Component({
template: `<input [ngModel]="a && b" (ngModelChange)="a && (b = $event)"/>`
})
export class MyComp {}
```
PR Close#54630
Fixes an edge case where a single-line elemnt with a long tag name a closing bracket on a new line was putting the control flow migration into an infinite loop.
Fixes#54587.
PR Close#54588
In rare cases people may use an underscore in their component names, which was not accounted for in the formatting portion of the migration.
fixes: #54532
PR Close#54533
Adds some logic to skip over `TestBed.configureTestingModule` calls where the `declarations` aren't initialized to an array. We can't migrate these cases, because test migrations don't have access to the Angular compiler. Previously the migration would throw a runtime error.
PR Close#54122
This addresses the offset issue caused when a switch case was empty with no spaces or children being affected by the markers that were added, but not accounted for in offset. The markers are not needed for empty content and can be safely removed in this case.
fixes: #53779
PR Close#53839
The formatting that would preserve attribute indents completely missed attributes that start on new lines rather than the same line as the opening element.
PR Close#53636
In cases where CommonModule was unsafe to remove but other imports were present, the symbol check would be skipped. This should run for all the possibly removed symbols for safety.
PR Close#53637
During formatting, attribute indentation is changed, and that can affect internationalized strings. This fix detects if an attribute value string is left open and skips formatting on those lines.
PR Close#53625
This addresses the case where modules are being used and declared in the same file as the component. It is unclear whether its safe to remove the common module in this case, so best to leave it.
PR Close#53575
Alan Agius