We don't collect/review the results from CI, so it's just a waste of CPU time.
It's sufficient if we are able to run these locally and manually.
PR Close#34057
This bring is changes to the @nodejs repository required for https://github.com/angular/angular/pull/33927. See release notes for more details: https://github.com/bazelbuild/rules_nodejs/releases/tag/0.41.0.
rules_nodejs is approaching 1.0 and breaking changes for that release are being made more frequently. In this release, the ts_devserver API changed and it no longer injects html script tags into a provided index.html file. The diff on this commit is large as this breaking change affects quite a few tests.
Also note that we don’t update @angular/bazel schematics and integration/bazel as 0.41.0 is not a recommended update for angular users yet due to the breaking changes in ts_devserver & web_package (now named pkg_web). When a suitable plain npm package that is in progress is finished then it will be possible to easily replace the html injection functionality removed from ts_devserver & pkg_web.
PR Close#33996
In order to keep integration tests on CI as determinitstic as possible,
we need to ensure that the same dependencies (including transitive ones)
are installed each time. One way to ensure that is using a lockfile
(such as `yarn.lock`) to pin the dependencies to exact versions. This
works as long as the lockfile itself is in-sync with the corresponding
`package.json`, which specifies the dependencies.
Ideally, we would run `yarn install` with the `--frozen-lockfile` option
to verify that the lockfile is in-sync with `package.json`, but we
cannot do that for integration projects, because we want to be able to
install the locally built Angular packages). Therefore, we must manually
esnure that the integration project lockfiles remain in-sync, which is
error-prone.
This commit introduces a helper script that performs some checks on each
project's (non-local) dependencies:
- Ensure that exact versions (not version ranges) are specified in
`package.json`. This reduces the probability of installing a breaking
version of a direct or transitive dependency, in case of an
out-of-sync lockfile.
- Ensure that the lockfile is in-sync with `package.json` wrt these
dependencies.
While these checks are not full-proof, they provide yet another line of
defense against indeterminism.
PR Close#33968
Since we cannot run `yarn install` with the `--frozen-lockfile` option
(because we want to be able to install the locally built Angular
packages), integration project lockfiles are susceptible to getting
out-of-sync with the corresponding `package.json`. When this happens,
yarn will install the latest available version that satisfies the
version range specified in `package.json`.
This commit adds another line of defense, by specifying exact versions
for the dependencies in `package.json` files (i.e. `1.33.7` instead of
`^1.33.0`). While transitive dependencies will be unpinned, this still
ensures that the same version of direct dependencies will be installed
in case of an out-of-sync lockfile, thus reducing the probability of
random failures.
PR Close#33968
In the `integration_test` CircleCI job, we run `yarn install` on all
projects in the `integration/` directory. If a project has no lockfile
or if the lockfile is out-of-sync with the corresponding `package.json`
file, then the installed dependency versions are no longer pinned, which
can result in different versions being installed between different runs
of the same job (if, for example, a new version is released for a
package) and breaks hermeticity.
This could be prevented by using the `--frozen-lockfile` option with
`yarn install`, but this is not possible with the current setup, because
yarn needs to be able to install the locally built Angular packages,
whose checksums will be different from the ones in the lockfile.
Therefore, we have to manually ensure that the lockfiles remain in-sync
with the corresponding `package.json` files for the rest of the
dependencies.
For example, previously, [cli-hello-world-lazy/yarn.lock][1] had an
entry for `@angular-devkit/build-angular@0.900.0-next.9` (pinned to
`0.900.0-next.9`), but [cli-hello-world-lazy/package.json][2] specified
the `@angular-devkit/build-angular` version as `^0.900.0-rc.0` (note the
leading caret). As a result, since the version in the lock file does not
much the one in `package.json`, the lockfile is ignored and the latest
available version that matches `^0.900.0-rc.0` is installed.
This, for example, started causing unrelated CI failures ([example][3]),
when `@angular-devkit/build-angular@9.0.0-rc.3` was released with a size
improvement.
This commit ensures that all integration projects have a lockfile and
that lockfiles are up-to-date (with the current `package.json` files).
[1]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/yarn.lock#L13
[2]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/package.json#L26
[3]: https://circleci.com/gh/angular/angular/535959#tests/containers/2
PR Close#33968
Commit 53fc2ed8bf345222e0c3d53ce7f13a4f27f3052e added support for
determining index types accessed using index signatures, but did not
include support for index types accessed using dot notation:
```typescript
const obj<T>: { [key: string]: T };
obj['stringKey']. // gets `T.` completions
obj.stringKey. // did not peviously get `T.` completions
```
This adds support for determining an index type accessed via dot
notation by rigging an object's symbol table to return the string index
signature type a property access refers to, if that property does not
explicitly exist on the object. This is very similar to @ivanwonder's
work in #29811.
`SymbolWrapper` now takes an additional parameter to explicitly set the
type of the symbol wrapped. This is done because
`SymbolTableWrapper#get` only has access to the symbol of the index
type, _not_ the index signature symbol itself. An attempt to get the
type of the index type will give an error.
Closes#29811
Closes https://github.com/angular/vscode-ng-language-service/issues/126
PR Close#33884
Now that all compile decisions are determined by the define=angular_ivy_enabled
flag, we can remove the setting of the define=compile flag throughout the repo.
PR Close#33983
Use angular_ivy_enabled to determine if Ivy is being used for the ivy_test_selector.ts symbols.
Additionally, remove the reflect_metadata genrules as we not longer have a "jit" compile option
so all possible invocations result in the same generated file. Instead we can just commit this
file.
PR Close#33983
We need to migrate to using angular_ivy_enabled value to determine whether to use
Ivy or ViewEngine for package building scripts and for size-tracking and
symbol-extract tooling.
PR Close#33983
Since config=ivy now sets the define=compile flag and the define=angular_ivy_enabled
flag to cause usage of Ivy, we can update all of the documentation and scripts that
reference compile=aot to use config=ivy.
PR Close#33983
Beginning of migration away from --define=compile=* to --define=angular_ivy_enabled=*.
Additionally, to make it clearer to developers, we will encourage use of --config=ivy
instead of directy setting the --define flag, this abstraction will allow us more
flexibility as we move foward with relation to our compile decisions at build time.
PR Close#33983
Since we created the migration guide for the `missing-injectable` schematic, the schematic
changed in various ways. e.g. the migration no longer migrates classes passed to `useExisting`
Additionally the migration has been expanded to handle another Ivy breaking change where
providers like `{provide: X}` will be intepreted as `{provide: X, useClass: X}`. This pattern should
be documented in the migration guide.
PR Close#33960
Prior to this commit, there was a runtime check in i18n logic to make sure "other" case is always present in an ICU. That was not a requirement in View Engine, so ICUs that previously worked may produce errors. This commit removes that restriction and adds support for ICUs without "other" cases.
PR Close#34042
Move a view only if it would end up at a different place.
Otherwise we would do unnecessary processing like DOM manipulation, query notifications etc.
Thanks to @pkozlowski-opensource for the change.
PR Close#34052
When inserting a `viewRef` it is possible to not provide
an `index`, which is regarded as appending to the end of
the container.
If the `viewRef` already exists in the container, then
this results in a move. But there was a fault in the logic
that computed where to insert the `viewRef` that did not
account for the fact that the `viewRef` was already in
the container, so the insertion `index` was outside the
bounds of the array.
Fixes#33924
PR Close#34052
Prior to this commit, all styles extracted from Component's template (defined using <style> tags) were ignored by JIT compiler, so only `styles` array values defined in @Component decorator were used. This change updates JIT compiler to take styles extracted from the template into account. It also ensures correct order where `styles` array values are applied first and template styles are applied second.
PR Close#34017
Previously if a type was returning itself it would cause an infinite loop in tsickle. We worked around it with a type that alises to `any`. Now that the issue has been resolved in tsickle, we can clean up the workaround.
PR Close#34019
When performing diagnostic checks or completions, we should take into
account members and properties in the base class, if any. Otherwise, the
language service will produce a false error.
PR closes https://github.com/angular/vscode-ng-language-service/issues/93
PR Close#34041
This commit fixes a compatibility bug where pre-order lifecycle
hooks (onInit, doCheck, OnChanges) for directives on the same
host node were executed based on the order the directives were
matched, rather than the order the directives were instantiated
(i.e. injection order).
This discrepancy can cause issues with forms, where it is common
to inject NgControl and try to extract its control property in
ngOnInit. As the NgControl directive is injected, it should be
instantiated before the control value accessor directive (and
thus its hooks should run first). This ensures that the NgControl
ngOnInit can set up the form control before the ngOnInit
for the control value accessor tries to access it.
Closes#32522
PR Close#34026
These apis have been deprecated in v8, so they should stick around till v10,
but since they are defunct we are removing them early so that they don't take up payload size.
PR Close#33949
In ViewEngine we were only generating code for exported classes, however with Ivy we do it no matter whether the class has been exported or not. These changes add an extra flag that allows consumers to opt into the ViewEngine behavior. The flag works by treating non-exported classes as if they're set to `jit: true`.
Fixes#33724.
PR Close#33921
At the end of the `integration/run_tests.sh` script, we check and upload
the payload sizes of UMD bundles in `dist/packages-dist/`. At some
point, we started sharding the integration tests on CI to speed the
overall build time. As a result, checking and uploading of UMD bundle
sizes was run multiple times (once per shard).
Given that the data is identical on each shard, the data was just
overwriting the previously uploaded data. Even if the end result is the
same, checking and uploading the data multiple times is wasteful.
This commit fixes `integration/run_tests.sh` to only check/upload UMD
bundle sizes on the 1st shard.
PR Close#33987
The change type was only recorded for `aio/` and was not correct anyway.
For example:
- It considered `package.json` changes as `application` (even if only
`package.json` and `yarn.lock` had changed).
- It failed to account for changes in `@angular/*` dependencies, when
using the locally built Angular packages (instead reporting them as
`other`).
- It only looked at the last commit, so it failed to provide accurate
information for multi-commit builds (which are rare, but possible).
For the above reasons (and because there is no straight-forward way of
fixing it), this commit removes the change type from the uploaded data.
If necessary, it is still possible to find the type of changes from the
uploaded info (e.g. extract the associated commits and look at their
changes using git).
PR Close#33987
As part of the `payload-size` npm script in `aio/package.json` (which is
run on CI), the sizes of the angular.io app bundles are checked to
ensure they do not exceed certain limits and are also uploaded to
Firebase to be available for later analysis. The uploaded data include
the type of the changes (dependencies only, application only, or both).
The type of changes is inferred by looking at the files that have
changed inside the `aio/` directory.
When the `payload-size.sh` script was first introduced, the only files
that could affect bundle sizes were inside the `aio/` directory.
Therefore, the script would skip uploading the data and checking the
sizes if no changes were detected inside the `aio/` directory.
However, this assumption stopped being valid over time. For example:
- We started tracking/checking bundle sizes when building the angular.io
app with the locally built Angular packages (which live outside the
`aio/` directory.
- Due to CircleCI limitations, the `CI_COMMIT_RANGE` environment
variable (which is used for determining what files have been affected)
stopped reflecting the whole commit range of the build and only
included the last commit instead.
Based on the above, there were many cases were size data would not be
uploaded to Firebase, even when they may have been affected (because the
affecting changes were outside `aio/` - e.g. in framework packages).
This makes it harder to analyze size regressions, because important
data-points are missing.
Even worse, in these cases, the sizes were not even checked against the
specified limits, thus making it possible for size regressions to go
unnoticed (unless caught by other similar tests).
This commit fixes the `scripts/ci/payload-size.sh` script to always
track and check payload sizes for angular.io bundles.
NOTE: This change will result in more data being recorded (i.e.
recording data when it is not possible for the bundle sizes to
have been affected by the changes). This is still preferable to
failing to record and/or check when sizes could have been
affected.
PR Close#33987
Micro-benchmarks were broken after we've introduced concept of
DECLARATION_COMPONENT_VIEW on LView (after this change embedded
views must have a pointer to a parent LView).
PR Close#34031
The root view case is already covered by the existing code in the
getRenderParent function so no need to have an explicit checks
(and associated memory reads) again.
PR Close#33988
We need to make is_ivy_enabled public to allow the internal i18n
build rule to rely on it rather than relying on compile_strategy.
After we move the internal i18n rule to rely on is_ivy_enabled,
compile_strategy can then be removed.
PR Close#33992
Previously, our incremental build system kept track of the changes between
the current compilation and the previous one, and used its knowledge of
inter-file dependencies to evaluate the impact of each change and emit the
right set of output files.
However, a problem arose if the compiler was not able to extract a
dependency graph successfully. This typically happens if the input program
contains errors. In this case the Angular analysis part of compilation is
never executed.
If a file changed in one of these failed builds, in the next build it
appears unchanged. This means that the compiler "forgets" to emit it!
To fix this problem, the compiler needs to know the set of changes made
_since the last successful build_, not simply since the last invocation.
This commit changes the incremental state system to much more explicitly
pass information from the previous to the next compilation, and in the
process to keep track of changes across multiple failed builds, until the
program can be analyzed successfully and the results of those changes
incorporated into the emit plan.
Fixes#32214
PR Close#33971
