There are some ZoneJS tests that fork the zone from the `describe` block
for testing the zone patching. This does cause the Jasmine `done`
function later in `it` specs to be invoked in the sync-test zone from
the original `describe` block. The `done` implementation now has
changed with the Karma Jasmine update and breaks because it now causes
tasks to be scheduled.
It is conceptually incorrect/invalid to take the describe sync zone and
run test logic with that sync zone.
```
An error was thrown in afterAll
error properties: Object({ originalStack: 'Error: Cannot call jasmine.execute().forceTask from within a sync test (syncTestZone for jasmine.describe#FileReader).
at new ZoneAwareError (packages/zone.js/test/browser_test_rollup.umd.js:98:37)
at e.onScheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:158:196)
at e.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:7529)
at t.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3539)
at t.scheduleMicroTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3791)
at r.execute (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:166:4312)
at queueRunnerFa ...
at <Jasmine>
```
As mentioned in the previous commit that ensured that the Zone name is
included in errors raised by the `SyncTestZoneSpec`, we can now include
the Jasmine describe block descriptions in such errors.
Errors can often happen when users accidentally try to set up Angular
tests without an `it` block. Resulting in errors where it's not clear
at all which describe block (of potentially a large repository) is
involved:
```
An error was thrown in afterAll
error properties: Object({ originalStack: 'Error: Cannot call XX from within a sync test.
at new ZoneAwareError (packages/zone.js/test/browser_test_rollup.umd.js:98:37)
at e.onScheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:158:196)
at e.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:7529)
at t.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3539)
at t.scheduleMicroTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3791)
at r.execute (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:166:4372)
at queueRunnerFa ...
at <Jasmine>
```
We now include the describe block description in the error, so that it
is easier to figure out the location of the culprit code.
The sync-test zone is used in e.g. `describe` to raise an error when
there is asynchronous code scheduled in describe blocks. This commit
includes the zone name in such thrown errors to allow for us to include
the jasmine describe name in the error. This will be wired up in the
jasmine zonejs patches separately.
In the fake async test for `zone.js` there is some logic to test various
prefixes of the request animation frame functions. This logic does not
have any effect currently, except for generating the same test at
maximum three times.
This commit fixes the test to actually test what it meant to do
initially.
Karma jasmine updated the `jasmine-core` dependency. Jasmine is now more
strict when:
* The done callback is invoked multiple times
* The done callback is used, while a promise is also returned
* The done callback is treated as error when e.g. a number is returned
as first argument. This was the case with `requestAnimationFrame`.
Currently tests written using `waitForAsync` would be prone to Jasmine
warnings or errors (depending on the version) for tests incorrectly
invoking asynchronous jasmine `done` callbacks multiple times.
This can happen because the async test zone logic schedules the
`done` callback to be called using `setTimeout`, but this could
be invoked multiple times, causing multiple `done` invocations to
be scheduled. Most of the issues have been resolved with #45025,
but it does not solve the case of multiple tasks finished and callbacks
being scheduled.
Technically, the current logic is built in way that _should_ result in
`_finishCallbackIfDone` and eventually the `done` callback to be invoked
at maximium once. This is unfortunately not the case in some rather
advanced/unexpected scenarios (like our AngularJS upgrade tests) where
the scenario is the following (and microtasks from before the actual
`waitForAsync` spec are still completing -- which is valid):
```
1. A test `beforeEach` schedules a microtask in the ProxyZone.
2. An actual empty `it` spec executes in the AsyncTestZone` (using e.g. `waitForAsync`).
3. The `onInvoke` invokes `_finishCallbackIfDone` because the spec runs synchronously.
4. We wait the scheduled timeout (see below) to account for unhandled promises.
5. The microtask from (1) finishes and `onHasTask` is invoked.
--> We register a second `_finishCallbackIfDone` even though we have scheduled a timeout.
--> we execute the `done` callback twice because the async zone spec state is "stable"
```
The jasmine seed generator is only used in a single karma configuration
file. Used by the legacy build and the Saucelabs/ZoneJS Karma jobs.
We should move the separate script code directly into the config to make
it clear that the seed generation is not used elsewhere, and to simplify
the Starlark code.
PR Close#46798
We have a file called `test-events.js` (named in an ambiguous way
anyway) that runs for all Karma web tests and configures ZoneJS to
not patch the `scroll` event. There are two issues:
1. The patch applies to all web tests. This could cause unexpected
issues.
2. The file is named ambiguously and also is placed at the project root,
in a wrong spot.
Additionally, the test doesn't even fail when the file is removed. This
commit applies the Zone config locally to the closest build target and
also reworks the test to actually ensure it's testing what it describes.
PR Close#46511
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Close#44913
The following case is not handled correctly by `zone.js`.
```
const delayedPromise = new Promise((resolve) => {
setTimeout(resolve, 1, 'timeout');
});
new Promise((resolve) => {
resolve(delayedPromise);
resolve('second call');
}).then(console.log);
```
It should output `timeout`, since the promise is resolved by the
1st resolve, the `second call` should be ignored.
So this is a bug that the original implementation not ensure the
`resolve` is only called once.
PR Close#45283
The `patchCallbacks` is used for patching the `document.registerElement` and
`customElements.define`. We explicitly wrap the patching code into try-catch since
callbacks may be already patched by other web components frameworks (e.g. LWC), and they
make those properties non-writable. This means that patching callback will throw an error
`cannot assign to read-only property`. See this code as an example:
https://github.com/salesforce/lwc/blob/master/packages/@lwc/engine-core/src/framework/base-bridge-element.ts#L180-L186
We don't want to stop the application rendering if we couldn't patch some
callback, e.g. `attributeChangedCallback`.
PR Close#42546
PR Close#45400
We must read `Symbol.species` safely because `this` may be anything. For instance, `this`
may be an object without a prototype (created through `Object.create(null)`); thus
`this.constructor` will be undefined. One of the use cases is SystemJS creating
prototype-less objects (modules) via `Object.create(null)`. The SystemJS creates an empty
object and copies promise properties into that object (within the `getOrCreateLoad`
function). The zone.js then checks if the resolved value has the `then` method and invokes
it with the `value` context. Otherwise, this will throw an error: `TypeError: Cannot read
properties of undefined (reading 'Symbol(Symbol.species)')`.
PR Close#45369
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
Before this change, the macrotask for `setInterval(callback, ms)` was no
longer tracked by `TaskTrackingZoneSpec` after the `callback` was
invoked for the first time. Now the periodic macrotask is tracked until
it is cancelled, e.g. `clearInterval(id)`.
BREAKING CHANGE: in TaskTrackingZoneSpec track a periodic task until it is cancelled
The breaking change is scoped only to the plugin
`zone.js/plugins/task-tracking`. If you used `TaskTrackingZoneSpec` and
checked the pending macroTasks e.g. using `(this.ngZone as any)._inner
._parent._properties.TaskTrackingZone.getTasksFor('macroTask')`, then
its behavior slightly changed for periodic macrotasks. For example,
previously the `setInterval` macrotask was no longer tracked after its
callback was executed for the first time. Now it's tracked until
the task is explicitly cancelled, e.g with `clearInterval(id)`.
fixes 45350
PR Close#45391
Jasmine checks internally if `process` and `process.on` is defined. Otherwise,
it installs the browser rejection handler through the `global.addEventListener`.
This code may be run in the browser environment where `process` is not defined, and
this will lead to a runtime exception since Webpack 5 removed automatic Node.js polyfills.
PR Close#42260
PR Close#45392
For legacy browsers, we still use the eventNames array to patch event instead of
using `Object.getOwnPropertyNames()` to keep backward compatibility.
PR Close#40962
Zone.js supports the google closure compiler in the advance optimization mode,
to prevent closure compiler modify the `onProperty` name such as `Element.prototype.onclick`,
Zone.js implements the `onProperty` patch logic by declaring all the
event names in the source code, this increases the bundle size and also require
updating the event names array to keep the information updated.
Now google closure compiler has the required event names defined in the built-in
externs files, so zone.js can use more simple implementation and decrease the bundle size
of zone.js (about 4k).
PR Close#40962
Close#43346
From electron 14, the `CallbacksRegistry` is moved to `@electron/remote` package,
so all `remote` call between `main` process and `renderer` process is
not being patched since the new version of electron released.
Also `CallbacksRegistry` is not exported outside, so this commit make a
`hack` patch to load `CallbacksRegistry` from
`@electron/remote/dist/src/renderer/callbacks-registry` for patching.
PR Close#45073
Close#42834
In the new version fo Mocha, all global test functions are from `global`
object instead of `Mocha` object. Adn the current `zone.js` Mocha
patch's logic looks like this.
```
global.describe = Mocha.describe = function() {
return originalMochaDescribe.apply(this, arguments);
}
```
and `originalMochaDescribe` is the unpathced Mocha implementation
looks like this
```
function describe() {
return context.describe(...);
}
```
And the `context` will finally delegate to `global.describe()`,
so the current `zone.js` patch causes infinite loop.
This commit will not patch function of `Mocha` object any longer.
PR Close#45047
`AsyncTestZoneSpec` triggers jasmine `done()` function multiple times
and causes warning
```
An asynchronous function called its 'done' callback more than once. This is a bug in the spec, beforeAll, beforeEach, afterAll, or afterEach function in question. This will be treated as an error in a future version. See<https://jasmine.github.io/tutorials/upgrading_to_Jasmine_4.0#deprecations-due-to-calling-done-multiple-times> for more information
```
The reproduce case will be running some `Zone.run()` inside
`waitForAsync()`.
```
it('multiple done', waitForAsync(() => {
Zone.current.run(() => {});
Zone.current.run(() => {});
}));
```
The reason the `done()` is called in the `onInvoke()` hook is to handle
the case that the testBody is totally sync, but we should only do this
check for the entry function not for all `Zone.run()` scenario.
Another issue is if we run nested zone inside `waitForAsync()`, the
`onHasTask()` hook will be triggered multiple times, and cause `done()`
be triggered multiple times, so we need to only trigger the `done()`
when the zone is `AsyncTestZone`.
PR Close#45025
Fixes formatting in one of the Zone BUILD files.
The lint check on the renovate branch did not check
formatting as it seems. Needs more investigation as
the PR was green.
PR Close#44912
Updates the postinstall patch for the benchmark macro rule from dev-infra.
We moved the ZoneJS setup to the bundler. This was necessary in order to
switch away from the Go-based (windows-incompatible, m1-incompatible)
concatjs devserver to a rather basic HTTP server (also provided by dev-infra now).
PR Close#44830
Paul Gschwendtner