Which @angular/* package(s) are the source of the bug?
zone.js
Is this a regression?
Yes
Description
zone.js attempts to monkey-patch Jasmine's GlobalErrors, for reasons that aren't entirely clear to me. It's a no-op because it happens after Jasmine has already constructed its GlobalErrors instance. If the monkey-patching occurred early enough to have any effect, it would crash Jasmine beginning with the next jasmine-core release because GlobalErrors has required constructor parameters and zone.js's monkey patch fails to forward them
My recommendation is to stop monkey patching GlobalErrors altogether. Presumably it's not doing anything important, if nobody noticed that it wasn't working. And any monkey patching creates a situation where any future version of jasmine-core could be incompatible, since you're depending on private interfaces that are outside of the scope of semver. So the less of it you can do, the better. But if you have to monkey patch GlobalErrors, it would be best to forward all constructor arguments to the real thing.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run ng version)
Anything else?
No response
Which @angular/* package(s) are the source of the bug?
zone.js
Is this a regression?
Yes
Description
zone.js attempts to monkey-patch Jasmine's
GlobalErrors, for reasons that aren't entirely clear to me. It's a no-op because it happens after Jasmine has already constructed itsGlobalErrorsinstance. If the monkey-patching occurred early enough to have any effect, it would crash Jasmine beginning with the next jasmine-core release because GlobalErrors has required constructor parameters and zone.js's monkey patch fails to forward themMy recommendation is to stop monkey patching
GlobalErrorsaltogether. Presumably it's not doing anything important, if nobody noticed that it wasn't working. And any monkey patching creates a situation where any future version of jasmine-core could be incompatible, since you're depending on private interfaces that are outside of the scope of semver. So the less of it you can do, the better. But if you have to monkey patchGlobalErrors, it would be best to forward all constructor arguments to the real thing.Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run
ng version)Anything else?
No response