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
Adds initial migration logic to convert decorator query declarations to
signal queries.
We will re-use more part of the signal input migration in follow-ups, to
properly migrate, and e.g. even handle control flow
PR Close#57556
This commit reduces the bundle size of `@angular/core` by 19.5 MB by excluding sourcemaps from the schematics.
Since the `esbuild` rule doesn't allow disabling sourcemaps directly, we work around this by setting the sourcemaps to `external`. Afterward, we filter the output to include only the `.js` files.
PR Close#57545
Adds initial migration logic to convert decorator query declarations to
signal queries.
We will re-use more part of the signal input migration in follow-ups, to
properly migrate, and e.g. even handle control flow
PR Close#57525
This removes an unnecessary type wrapping that can be removed because
`Replacements` is expected to be serializable by default.
Similar to how it's done in `TsurgeComplexMigration`.
PR Close#57501
Introduces a simpler, smaller variant of the current `Tsurge` migration
class. The difference is simply that for the migration phase (the third
stage), some migrations do not need a full set of workers re-analyzing
every compilation unit again to compute the "final migration
replacements".
This can be the case, for example, if a migration eagerly computes all
replacements in the analyze stage, visiting every unit, and then after
deriving the global metadata, problematic replacements are simply
filtered (e.g. via some unique IDs again).
PR Close#57484
This commit simplifies the batching support for the signal input
migration by using the new tsurge framework we've built.
This allows for consistent setup across all possible entry-points and
also simplifies the 1P setup given that we can simply use the Tsurge
macros, instead of having to maintain our own Go-based runner.
PR Close#57451
* Improves some of the generic assignability for tsurge. Anything is
allowed to be returned from an overridden `prepareProgram` method.
This is useful for the signal input migration.
* Passes the absolute root paths to migrations. This is helpful for the
signal input migration and there is no other way to access it. It's
better to pass specifically, compared to passing the whole unsafe
`ParsedConfiguration` object.
PR Close#57451
Introduces a migration framework to build batchable migrations that
can run in Large Scale mode against e.g. all of Google, using workers.
This is the original signal input migration infrastructure extracted
into a more generic framework that we can use for writing additional
ones for output, signal queries etc, while making sure those are not
scoped to a single `ts.Program` that limits them to per-directory
execution in very large projects (e.g. G3).
The migration will be updated to use this, and in 1P we will add
helpers to easily integrate such migrations into a Go-based pipeline
runner.
PR Close#57396
The migration was migrating all files in a project (like most migrations).
As there is no gain in migrating components used in test files. Excluding the test files reduces the migration noise.
PR Close#57317
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
Signal inputs are no longer updated by assignment, unlike `@Input()`, so
a good practice is adding `readonly` for the `InputSignal`— which should
never be swapped out.
This is a safe operation because the migration skips all inputs that are
being written anyway.
PR Close#57368
In some cases, the migration can detect when `input()` as a shorthand
may be usable. This commit adds such detection and migrates inputs to
this form when possible.
PR Close#57368
Components with `jit: true` are not processed by the Angular compiler,
so we cannot ask the template checker for the parsed template; simply
because the template wasn't attempted to be parsed.
We still can migrate simple cases of such components, commonly seen in
unit tests. We do this by manually parsing the template and making use
of the reference fallback resolution that is also used for host bindings
(where we don't have any type check block information).
PR Close#57347
Instead of exposing just the `ts.CompilerOptions`, we should expose the
actual Angular compiler options throuhgout the signal input migration.
This will be useful for parsing templates, in cases of JIT-opted
components.
PR Close#57347
As of this commit, the migration will also inspect safe property reads
and migrate them, if they reference an input that is being migrated.
PR Close#57318
Instead of revisiting each source file, and each of its child nodes
twice, we now visit them together using a grouped AST visitor that only
traverses each source file once.
This seemed to speed up migration by 6-8% locally, but is likely
noticable better with large compilation scopes.
PR Close#57318
Instead of fiddling manually with the imports, which worked well, but
comes at a cost of complexity— we are now using the canonical import
manager. This simplifies deletion, insertion and updating of imports.
Notably, our import manager is not super great at preserving whitespaces
right now, but we assume a formatter runs over migrated code anyway.
PR Close#57318
Introduces a best effort mode for the signal input migration. This mode
can be used to aggresively migrate as much as possible, ignoring most
of the incompatibility reasons, like "writes to the input".
PR Close#57318
By default, we don't migrate inputs if they are part of e.g. `@if` for
now. That is because we don't have the template narrowing feature
available yet.
To improve impact of the migration until we have the narrowing, we add
some additional checks that allow us to migrate instances of inputs that
are part of e.g. `@if` but are actually not used inside (and hence are
guaranteed to be _not_ narrowed).
PR Close#57308
PR Close#57323
This changes the migration so that we don't generate `_1` suffixes when
a temporary variable wouldn't conflict with any variables in the lexical
scope.
In addition, if we discover conflicts, we try alternative suffixes that
seem more natural and follow style guides. E.g. `Value`, `Val` or
`Input`.
PR Close#57292
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
Makes a few optimizations in the utilities we use for dealing with imports in migrations. I didn't end up using these in the inject migration, but they should still come in handy. Includes:
1. Exiting `isReferenceToImport` early when the node being checked is an identifier and it doesn't match the identifier of the import. This saves us some type checker calls.
2. Adds the ability to pass a single string to `getImportSpecifiers`. This saves us unnecessary arrays and for loops.
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
Alan Agius