Previously, `CommonJsDependencyHost.collectDependencies()` would only
find dependencies via imports of the form `var foo = require('...');` or
`var foo = require('...'), bar = require('...');` However, CommonJS
files can have imports in many different forms. By failing to recognize
other forms of imports, the associated dependencies were missed, which
in turn resulted in entry-points being compiled out-of-order and failing
due to that.
While we cannot easily capture all different types of imports, this
commit enhances `CommonJsDependencyHost` to recognize the following
common forms of imports:
- Imports in property assignments. E.g.:
`exports.foo = require('...');` or
`module.exports = {foo: require('...')};`
- Imports for side-effects only. E.g.:
`require('...');`
- Star re-exports (with both emitted and imported heleprs). E.g.:
`__export(require('...'));` or
`tslib_1.__exportStar(require('...'), exports);`
PR Close#34528
Unlike in View Engine, we currently reset the dirty state of
components in the check no changes change detection cycle.
This means that components cannot be marked as dirty from
view lifecycle hooks because the dirty state is reset and
the lifecycle hooks do not run in the check no changes CD cycle.
PR Close#34495
Runs the styling benchmarks that have been added with 2e0b237646863562e336f370372b4b7f9e52d818
in benchpress. The goal is that these benchmarks can be wired up in
Latency Lab.
PR Close#34664
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).
This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)
NOTE: Although we are not currently using the Firebase emulator for
development/testing, we might want to use it in the future.
[1]: https://github.com/firebase/superstatic/issues/231#issuecomment-573034515
PR Close#34726
Currently the decorator handlers are run against all `SourceFile`s in the compilation, but we shouldn't be doing it against declaration files. This initially came up as a CI issue in #33264 where it was worked around only for the `DirectiveDecoratorHandler`. These changes move the logic into the `TraitCompiler` and `DecorationAnalyzer` so that it applies to all of the handlers.
PR Close#34557
This commit removes some test scenarios from `parsing-cases.ts` and
colocate them with the test code instead. This makes the tests easier to
read and understand.
PR Close#34716
This is recommended in the Bazel docs as $(location) is ambiguous and can mean either $(execpath) or $(rootpath) depending on the context.
PR Close#34589
Also add comment that cache_key version should be bumped when switching forks or branches and added a comment from @devversion explaining how the fallback cache key works.
PR Close#34589
This brings in a required fix to allow for 0.0.0 dev version of @angular/core for integration testing. Without this the following error is now observed:
```
This version of CLI is only compatible with Angular versions ^9.0.0-beta || >=9.0.0 <10.0.0,
but Angular version 0.0.0 was found instead.
```
NB: rc.7 breaks the cli-hello-world-ivy-i18n integration test
PR Close#34589
For the purposes of the integration test the zone.js script & bundle script tags can just go into the source index.html itself. The purpose of the integration test is is to test @angular/bazel & ng_module & ng_package so there is no need to exercise html_insert_assets in integration/bazel.
PR Close#34589