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
In Bazel, the `CI` environment variable is not set due to its hermetic nature. As a result, caching is enabled by default, which includes Vite pre-bundling. This is unnecessary in CI environments.
In some cases, this leads to errors during CI runs when the Vite build is closed or canceled prematurely, resulting in the following errors:
```
Error: R] The build was canceled
Error: R] Terminating worker thread [plugin angular-vite-optimize-deps]
```
PR Close#57863
This commit also performs lock file maintenance on all integration
tests, fixing some ambigous ESM/CJS dependency graph issues.
e.g.
```
Unknown error: Error [ERR_REQUIRE_ESM]: require() of ES Module /tmp/ng-integration-test-aTpQOT/test-sandbox/node_modules/string-width/index.js from /tmp/ng-integration-test-aTpQOT/test-sandbox/node_modules/cliui/build/index.cjs not supported.
Instead change the require of index.js in /tmp/ng-integration-test-aTpQOT/test-sandbox/node_modules/cliui/build/index.cjs to a dynamic import() which is available in all CommonJS modules.
------------------------------------------
```
Closes#56261.
PR Close#56364
Trigger an error when attempting to enable size-tracking for a project not listed in the integration-payload.json file.
Before this update, size-checks would succeed even if the project wasn't included in the file size limit.
PR Close#55708
This commit updates the platform-server tests to use the new application builder, with this change we also have to remove the sizechecks since esbuild will do code motion and split the code into multiple chunks example `chunk-QUKLKPSE.js`.
PR Close#53205
Prior to this commit relative HTTP requests were not being resolved to absolute even thought the behaviour is documented in https://angular.io/guide/universal#using-absolute-urls-for-http-data-requests-on-the-server.
This caused relative HTTP requests to fail when done on the server because of missing request context. This change is also required to eventually support HTTP requests handled during prerendering (SSG).
Closes#51626
PR Close#52326
Since we updated the devkit dependencies, we need to update
the browserslist DB versions in integration tests to avoid
browser mismatches causing errors like the following:
```
BrowserslistError: [BABEL] /tmp/ng-integration-test-91jP3g/test-sandbox/node_modules/zone.js/fesm2015/zone.js: Unknown version 114 of edge (While processing: "base$0$0")
```
PR Close#50772
Prior to this change in some cases errors tht happen during routing were not being surfaced. This is due to the fact that the router has floating promises, and the platform was being destroyed prior to these being settled.
PR Close#50587
Previously, with `mergeMap` we did not cancel previous subscriptions to zoneIsStable which caused the application to be stablized before hand.
Closes: #50562
PR Close#50573
This commit updates the `@angular/common/http` and `@angular/platform-server` packages to allow dynamic import of the `xhr2` dependency. The `xhr2` dependency has side-effects that rely on a global scope and as a result in some environments those side-effectful calls fail. With the changes from this PR, the import is delayed until it's actually needed, which gives a chance for the underlying platform to setup global scope (via shims) as needed.
Co-authored-by: alan-agius4 <17563226+alan-agius4@users.noreply.github.com>
PR Close#50095
This commits update the platform-server test structure to add 2 applications in the Angular CLI workspace one based on ngmodules and another standalone. The same E2E suit is ran on both apps.
PR Close#49927
This commit updates the platform-server integration tests to use the Angular CLI as it makes it easier to add more tests and remove the custom webpack setup.
PR Close#49900
This commit fixes an issue were on the server the HTTP cache was being disabled prematurely which caused HTTP calls performed in `ngOnInit` life cycle hooks not to be cached.
PR Close#49826
This commit improves the HTTP transfer state integration test by using `provideClientHydration` method and validates that no HTTP calls are performed during the client bootstrapping.
PR Close#49810
Previously, since the `HttpXhrBackend` is a singleton, the macrotask was created and completed only for the initial request since it was stored as in property in the class instance. This commit replaces this logic to create a macro task for every XHR request.
Closes#49730
PR Close#49776
This commits adds `makeStateKey`, `StateKey` and `TransferState` methods in `@angular/core` as public API and deprecated the same exported symbols in `@angular/platform-browser`.
DEPRECATED: `makeStateKey`, `StateKey` and `TransferState` exports have been moved from `@angular/platform-browser` to `@angular/core`. Please update the imports.
```diff
- import {makeStateKey, StateKey, TransferState} from '@angular/platform-browser';
+ import {makeStateKey, StateKey, TransferState} from '@angular/core';
```
PR Close#49563
This commit adds a background macrotask when an XHR request is performed. The macrotask is started during `loadstart` and ended during `loadend` event.
The macrotask is needed so that the application is not stabilized during HTTP calls. This is important for server rendering, as the application is rendering when the application is stabilized.
The application is stabilized when there are no longer pending Macro and Micro tasks intercepted by Zone.js, Since an XHR request is none of these, we create a background macrotask so that Zone.js is
made aware that there is something pending.
Prior to this change, we patched the `HttpHandler` in `@angular/platform-server` but this is not enough, as there can be multiple `HttpHandler` in an application, example when importing `HttpClient` in a lazy loaded component/module.
Which causes a new unpatched instance of `HttpHandler` to be created in the child injector which is not intercepted by Zone.js and thus the application is stabalized and rendered before the XHR request is finalized.
NB: Zone.js is fundamental for SSR and currently, it's not possible to do SSR without it.
Closes: #49425
PR Close#49546
`ng-app` is an AngularJS attribute, see https://docs.angularjs.org/api/ng/directive/ngApp. Using this attribute on a non AngularJS element can cause DI issues in AngularJS when running an AngularJS and Angular application on the same page.
As such, we avoid such problems the Angular `ng-app` attribute is renamed to `ng-app-id`.
PR Close#49424
The mentioned 2 classes have been combined since it is no longer required to have a separate `SharedStylesHost` for SSR. This changes also reduces the memory usage footprint as remove 1 Map that stores the CSS strings.
PR Close#49424
Prior to this change component styles generated on the server where removed prior to the client side component being rendered and attached it's own styles. In some cases this caused flickering. To mitigate this `initialNavigation: enabledBlocking'` was introduced which allowed the remove of server styles to be defer to a latter stage when the application has finished initialization.
This commit changes the need for this, by not removing the server generated component styles and reuse them for client side rendering.
PR Close#48253
After the move of the `TransferState` logic, this file only contains a module that used to have the `TransferState` in provider list (but was refactored a while ago after `TransferState` became tree-shakable).
PR Close#49222
This commit adds the `isEmpty` method to the `TransferState` class to make it possible to check whether the state is empty or not. This is helpful in situations when the `TransferState` should be serialized and the content is transferred to the client (if the state is empty - certain operations can be omitted).
PR Close#46915
Switches the integration tests form Puppeteer/webdriver-manager to the
Bazel-managed Chromium/Chromedriver. This is now possible with the new
integration test rule for which we can consult the
`dev-infra/bazel/browsers` toolchain and setup environment variables.
This has been configured already in a previous commit.
This commit also includes some additional small cleanups necessary for
the new integration test rule:
* The `test.sh` scripts have been renamed as they would conflict with
the `test.sh` scripts generated by the integration test rule.
Previously this was not an issue because tests were declared at a
higher-level. As mentioned though this has other downsides and it is
trivial to rename the file.
* Related to the point above, since tests are now declared witin the
actual test folder (for perf e.g.), `package.json` files setting
`"type": "module"` will accidentally cause the `nodejs_test`-generated
files to be considered ESM. This is not correct and likely needs to be
fixed upstream in `rules_nodejs` where explicit `.cjs` extensions
should be used. This is only happening **once** in the `injectable-def`
test so it is acceptable doing that for now.
PR Close#44238
Sets up the test targets for integration tests with the new rule.
The targets will match the configuration of the previous integration
test setup (through the dictionary in a `bzl` file).
Note: We already add `setup_chromium` based on whether Chromium tests
run as part of this integration test. In a follow-up commit we can then
remove puppeteer and rely on the Bazel-managed version of Chromium.
PR Close#44238
Re-enables the platform-server integration test that we had
to disable when we landed the APF v13 changes.
We can re-enable it by setting up the `fullySpecified` option
similar to how the CLI does it.
PR Close#44055
Updates the platform-server integration test to rely on the v13 partial
compilation packages. This involves setting up the Babel linker plugin.
This is a great addition for coverage of the Babel linker plugin.
PR Close#43431
ChromeDriver now supports Apple Silicon ARM processors.
`webdriver-manager` versions 12.1.7 and earlier will, however,
incorrectly download the arm64 ChromeDriver regardless of the
system's architecture. This results in failure to run Protractor tests
on macOS with the error: `spawn Unknown system error -86`
This commit fixes the problem by upgrading `webdriver-manager` to
version 12.1.8, which includes a fix.
See also https://stackoverflow.com/questions/65618558.
PR Close#40756
Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target
bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may
generate different results, for example, Zone.js 0.11.0's issue is `package.json`
define files array which make the bundle only include the files in the files array.
So this PR install the zone.js package from the archive generated from `npm_package.pack` rule.
PR Close#38649
Close#35157
In the current version of zone.js, zone.js uses it's own package format, and it is not following the rule
of Angualr package format(APF), so it is not easily to be consumed by Angular CLI or other bundle tools.
For example, zone.js npm package has two bundles,
1. zone.js/dist/zone.js, this is a `es5` bundle.
2. zone.js/dist/zone-evergreen.js, this is a `es2015` bundle.
And Angular CLI has to add some hard-coding code to handle this case, o5376a8b139/packages/schematics/angular/application/files/src/polyfills.ts.template (L55-L58)
This PR upgrade zone.js npm package format to follow APF rule, https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/edit#heading=h.k0mh3o8u5hx
The updated points are:
1. in package.json, update all bundle related properties
```
"main": "./bundles/zone.umd.js",
"module": "./fesm2015/zone.js",
"es2015": "./fesm2015/zone.js",
"fesm2015": "./fesm2015/zone.js",
```
2. re-organize dist folder, for example for `zone.js` bundle, now we have
```
dist/
bundles/
zone.js // this is the es5 bundle
fesm2015/
zone.js // this is the es2015 bundle (in the old version is `zone-evergreen.js`)
```
3. have several sub-packages.
1. `zone-testing`, provide zone-testing bundles include zone.js and testing libraries
2. `zone-node`, provide zone.js implemention for NodeJS
3. `zone-mix`, provide zone.js patches for both Browser and NodeJS
All those sub-packages will have their own `package.json` and the bundle will reference `bundles(es5)` and `fesm2015(es2015)`.
4. keep backward compatibility, still keep the `zone.js/dist` folder, and all bundles will be redirected to `zone.js/bundles` or `zone.js/fesm2015` folders.
PR Close#36540
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context
* test //integration:bazel_test and //integration:bazel-schematics_test exclusively
* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute
```
//integration:bazel-schematics_test PASSED in 317.2s
//integration:bazel_test PASSED in 167.8s
```
* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure
* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test
@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.
NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.
PR Close#33927
This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome.
webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version.
Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall
"// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
}
This should speed up each integration postinstall by a few seconds.
Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted.
NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info.
Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it
Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version()
Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step
PR Close#35049
