* fix(core): introduce `BootstrapContext` for improved server bootstrapping
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.
Currently we construct the HMR replacement URL inline by calling into the native `URL` constructor. This can cause conflicts with user code that defines a symbol called `URL`.
These changes resolve the issue by moving the URL construction into a separate function. This has a secondary benefit of making the generated code easier to follow and allowing us to update the URL without changing the compiled code.
Fixes#61517.
PR Close#61550
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61316
Fixes that the runtime was throwing a DI error when attempting to inject a missing `useExisting` provider, despite the call being optional.
The problem was that when the provider has `useExisting`, we do a second `inject` call under the hood which didn't include the inject flags from the original call.
Fixes#61121.
PR Close#61152
Renderer2 and ElementRef didn't mention the Security-DomSanitizer method, this will add clarity for potential user what to expect. Also swap deprecated "callout" class to docs-alert
Fixes#51208 , #46904
PR Close#60708
This commit wraps the `fn` invocation with `try-finally`, ensuring that the pending task (added in [this commit](d5c6ee432f)) is always removed.
Prior to this commit, if a subscriber threw an error, it would prevent the application from becoming stable — though this shouldn't happen under normal scenarios because the error should be handled by the RxJS error handler or Angular's error handler.
Errors should not silently prevent the application from being rendered on the server.
PR Close#61028
Adds `__PURE__` annotations to `NOT_SET` and `EMPTY_CLEANUP_SET` to enable tree-shaking, even if they are not referenced. These variables are not dropped when Angular is imported from a module that has `sideEffects` set to `true`.
PR Close#60979
This is a roll forward of commit d5a8a1c524. Nothing is meaningfully different, as we're trying again to see if the CI failure is reproducible.
PR Close#60622
This allows any components individually bootstrapped to inherit from a unique `Injector`. This is useful when bootstrapping multiple root components with different providers.
For now, the function is private while we explore potential designs to consolidate it with the existing `ApplicationRef.prototype.bootstrap` method.
PR Close#60622
The previous message would sound like a full sentence when using a signal without `()` (Example: Unsupported styling type function: [Input Signal: neutral]). The new formatting makes it a bit more obvious that the type itself is the problem.
PR Close#59563
This commit updates the OutletInjector and related code to avoid special handling of that injector. The main code that had special handling was refactored to no longer require is in https://github.com/angular/angular/pull/56763, this commit completes the cleanup.
PR Close#58351
When the HMR is enabled in Angular, all `@defer` block dependencies are loaded
eagerly, instead of waiting for configured trigger conditions. From the DX perspective,
it might be seen as an issue when all dependencies are being loaded eagerly. This commit
adds a logic to produce a message into the console to provide more info for developers.
PR Close#60533
This regexp accidentally worked. It was splitting by individual character and putting a pipe in rather than splitting by set of event types
PR Close#60592
We can simplify signature of listenToDirectiveOutput by passing less
arguments (some of them can be derived from already passed arguments).
PR Close#60547
When the browser parses a valid html5 response like this:
```html
<!-- ... -->
<title>My page</title>
</head>
<!--nghm-->
<app-root></app-root>
<!-- ... -->
```
The resulting DOM will only start adding nodes to the body when it
runs into the first non-header tag. E.g.:
```yml
- head
- title "My page"
- comment "nghm"
- body
- app-root
```
This isn't a sign that comments are modified, so it seems worth to
handle it gracefully.
PR Close#60429
This should prevent defer timers from impacting app stability by executing them outside of the zone, similar to other defer triggers.
fixes: #60373
PR Close#60392
The signals primitives package understands the equals option now
so we can pass it to the signal / computed creation methods instead
of manually assigning the equality function on a reactive node.
PR Close#60364
In the case that a route was lazy loaded, some triggers would never properly finish hydrating due to things firing before the route finished resolving.
This will find the topmost parent defer block and ensure the registry knows about it before trying to hydrate.
In the case that the registry does not yet know, just the affected triggers await app stability before initializing.
fixes#59997
PR Close#60203
In this commit, we add injector token information to the error message to improve debugging and context awareness, because it is hard to capture the `inject()` stack trace in asynchronous contexts.
PR Close#60009
In this commit, we check whether the application is destroyed before initializing event replay. The application may be destroyed before it becomes stable, so when the `whenStable` resolves, the injector might already be in a destroyed state. As a result, calling `injector.get` would throw an error indicating that the injector has already been destroyed.
PR Close#59789
