This allows us to update the version of the package in a single place for all tests.
Notable exemption of this is aio which currently doesn't depend on anything installed in the root.
PR Close#34002
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
In View Engine, providers which neither used `useValue`, `useClass`,
`useFactory` or `useExisting`, were interpreted differently.
e.g.
```
{provide: X} -> {provide: X, useValue: undefined}, // this is how it works in View Engine
{provide: X} -> {provide: X, useClass: X}, // this is how it works in Ivy
```
The missing-injectable migration should migrate such providers to the
explicit `useValue` provider. This ensures that there is no unexpected
behavioral change when updating to v9.
PR Close#33709
In #33046, internal uses of `zone.js` were switched to reference it
directly from source (built with Bazel) instead of npm. As a result, the
necessary scripts were updated to build `zone.js` as necessary. However,
some `integration/**/debug-test.sh` scripts were missed (apparently
because they are not used on CI, but only locally as helpers for
debugging the integration projects).
This commit updates the `scripts/build-packages-dist.sh` script to also
build `zone.js`, so that other scripts (such as the various
`debug-test.sh` scripts) can use it.
PR Close#33733
We should not migrate the reference from `useExisting`. This is because
developers can only use the `useExisting` value as a token. e.g.
```ts
@NgModule({
providers: [
{provide: AppRippleConfig, useValue: rippleOptions},
{provide: MAT_RIPPLE_OPTIONS, useExisting: AppRippleConfig},
]
})
export class AppModule {}
```
In the case above, nothing should be decorated with `@Injectable`. The
`AppRippleConfig` class is just used as a token for injection.
PR Close#33286
Improves the `missing-injectable` migration test case in the
`ng_update_migrations` integration test by adding scenarios
for the recent changes that have been made to the migration.
e.g. 5557dec120
PR Close#33223
Updates the Angular CLI version in the `ng_update_migrations`
integration test. Since refactorings are made to the `ng update`
command implementation, we want to make sure that everything
works as expected for the migrations in version 9.
PR Close#33223
Adds a new test to the `ng_update_migrations` that ensures
that the `missing-injectable` migration works properly in a
real CLI project. Additionally this ensures that the
`missing-injectable` and `undecorated-classes-with-di` migrations
play nicely together.
PR Close#32349
Creates anew integratin test for `ng-update` migrations. The
integration test uses an Angular CLI project that will be updated
using the latest package output symlinked from then `./dist/packages-dist`.
This allows us to ensure that migrations work in real CLI projects.
Another big benefit is that the Angular version is updated to the
latest. This is something we couldn't replicate in unit tests but
is extremely important. It's important because compilation could
break with newer Angular versions (note that migrations are always
executed after the new angular version has been installed).
PR Close#32349
Igor Minar
George Kalpakas
Filipe Silva
Paul Gschwendtner
JiaLiPassion
Pete Bacon Darwin