Commit Graph

33 Commits

Author SHA1 Message Date
JiaLiPassion f8956adb73 build: update zone.js version to 0.11.3 (#39317)
Update the version of `zone.js` from 0.10.3 to 0.11.3 inside
Angular repo.

PR Close #39317
2020-11-12 13:51:29 -08:00
Bjarki cfac8e0764 build: upgrade karma to version 4.4.0 (#39180)
Upgrade the karma dependency to version 4.4.0 in the root package.json
and in integration tests. Compared to version 4.3.0, which most of the
packages were previously depending on, it has the following changes:

Bug Fixes
- runner: remove explicit error on all tests failed

Features
- client: Add trusted types support
- Preprocessor can return Promise
- config: add failOnSkippedTests option.
- config: clientDisplayNone sets client elements display none.
- deps: Remove core-js dependency.

The motivation for upgrading the package is the Trusted Types support
that it adds, which is necessary to enable Trusted Types in Angular's
unit tests.

PR Close #39180
2020-10-20 16:27:54 -07:00
JiaLiPassion d37939623f test(zone.js): test zone.js package with tgz (#38649)
Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target
bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may
generate different results, for example, Zone.js 0.11.0's issue is `package.json`
define files array which make the bundle only include the files in the files array.
So this PR install the zone.js package from the archive generated from `npm_package.pack` rule.

PR Close #38649
2020-10-19 08:06:11 -07:00
Andrew Kushnir 8fd25d9614 docs: remove IE10 references from comments in the code (#39090)
PR Close #39090
2020-10-13 15:51:49 -07:00
Andrew Kushnir a051d97429 test(core): remove IE10 reference from `browserslist` files (#39090)
This commit updates `browserslist` files to exclude IE10 references.

PR Close #39090
2020-10-13 15:51:49 -07:00
JiaLiPassion 8fbf40bf40 feat(core): update reference and doc to change `async` to `waitAsync`. (#37583)
The last commit change `async` to `waitForAsync`.
This commit update all usages in the code and also update aio doc.

PR Close #37583
2020-08-03 12:54:13 -07:00
Paul Gschwendtner d12cdb5019 fix(migrations): do not incorrectly add todo for @Injectable or @Pipe (#37732)
As of v10, the `undecorated-classes-with-decorated-fields` migration
generally deals with undecorated classes using Angular features. We
intended to run this migation as part of v10 again as undecorated
classes with Angular features are no longer supported in planned v11.

The migration currently behaves incorrectly in some cases where an
`@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy`
lifecycle hook. We incorrectly add a TODO for those classes. This
commit fixes that.

Additionally, this change makes the migration more robust to
not migrate a class if it inherits from a component, pipe
injectable or non-abstract directive. We previously did not
need this as the undecorated-classes-with-di migration ran
before, but this is no longer the case.

Last, this commit fixes an issue where multiple TODO's could be
added. This happens when multiple Angular CLI build targets have
an overlap in source files. Multiple programs then capture the
same source file, causing the migration to detect an undecorated
class multiple times (i.e. adding a TODO twice).

Fixes #37726.

PR Close #37732
2020-06-25 14:22:08 -07:00
Joey Perrott d1ea1f4c7f build: update license headers to reference Google LLC (#37205)
Update the license headers throughout the repository to reference Google LLC
rather than Google Inc, for the required license headers.

PR Close #37205
2020-05-26 14:26:58 -04:00
Paul Gschwendtner 0577bf0e3e refactor: enable ng update migrations for v10 (#36921)
Enables the `ng update` migrations for v10. Status for individual
migrations:

**undecorated-classes-with-di**.

This migration dealt exlusively with inherited constructors and
cases where a derived component was undecorated. In those cases,
the migration added `@Directive()` or copied the inherited decorator
to the derived class.

We don't need to run this migration again because ngtsc throws if
constructor is inherited from an undecorated class. Also ngtsc will
throw if a NgModule references an undecorated class in the declarations.

***undecorated-classes-with-decorated-fields***

This migration exclusively deals with undecorated classes that use
Angular features but are not decorated. Angular features include
the use of lifecycle hooks or class fields with Angular decorators,
such as `@Input()`.

We want to re-run this migration in v10 as we will disable the
compatibility code in ngtsc that detects such undecorated classes
as `@Directive`.

**module-with-providers**:

This migration adds an explicit generic type to `ModuleWithProviders`.
As of v10, the generic type is required, so we need to re-run the
migration again.

**renderer-to-renderer2**:

We don't need to re-run that migration again as the
renderer has been already removed in v9.

**missing-injectable**:

This migration is exclusively concerned with undecorated
providers referenced in an `NgModule`. We should re-run
that migration again as we don't have proper backsliding
prevention for this yet. We can consider adding an error
in ngtsc for v10, or v11. In either way, we should re-run
the migration.

**dynamic-queries**:

We ran this one in v9 to reduce code complexity in projects. Instead
of explicitly passing `static: false`, not passing any object literal
has the same semantics. We don't need to re-run the migration again
since there is no good way to prevent backsliding and we cannot always
run this migration for future versions (as some apps might actually
intentionally use the explicit `static: false` option).

PR Close #36921
2020-05-06 15:06:10 -07:00
Paul Gschwendtner c24ad560fa feat(core): undecorated-classes migration should handle derived abstract classes (#35339)
In version 10, undecorated base classes that use Angular features need
to be decorated explicitly with `@Directive()`. Additionally, derived
classes of abstract directives need to be decorated.

The migration already handles this for undecorated classes that are
not explicitly decorated, but since in V9, abstract directives can be
used, we also need to handle this for explicitly decorated abstract
directives. e.g.

```
@Directive()
export class Base {...}

// needs to be decorated by migration when updating from v9 to v10
export class Wrapped extends Base {}

@Component(...)
export class Cmp extends Wrapped {}
```

PR Close #35339
2020-04-02 10:51:49 -07:00
Paul Gschwendtner 3d2db5c5f0 test: add integration test for undecorated-classes-with-decorated-fields migration (#35339)
We don't have an integration test for the `undecorated-classes-with-decorated-fields
migration. For consistency and to cover for the latest changes, we add
it to the `ng update` integration test.

PR Close #35339
2020-04-02 10:51:48 -07:00
JiaLiPassion c5df9ce474 build(zone.js): update zone.js version to 0.10.3 (#36214)
PR Close #36214
2020-03-31 10:59:17 -07:00
George Kalpakas fc325c49ec build(docs-infra): update project structure to cli@9 3/12 (`title in a h1 tag`) (#36015)
Make test description less implementation specific.

PR Close #36015
2020-03-18 10:00:01 -07:00
Greg Magolan dde68ff954 build: add npm_integration_test && angular_integration_test (#33927)
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as  `BUILD_WORKSPACE_DIRECTORY` will be set in that context

* test //integration:bazel_test and //integration:bazel-schematics_test exclusively

* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute

```
//integration:bazel-schematics_test                                      PASSED in 317.2s
//integration:bazel_test                                                 PASSED in 167.8s
```

* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure

* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test

@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.

NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.

PR Close #33927
2020-02-24 08:59:18 -08:00
Greg Magolan acfd0edd38 test: use puppeteer in integration tests and to download correct chromedriver (#35049)
This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome.

webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version.

Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall

"// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
}
This should speed up each integration postinstall by a few seconds.

Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted.

NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info.

Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it

Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version()

Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step

PR Close #35049
2020-02-11 13:16:52 -08:00
Igor Minar ea37e82e69 build: consolidate @angular-devkit/build-angular to the root package.json (#34002)
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
2019-12-02 10:49:12 -08:00
George Kalpakas 4ece0eb27c build: use exact versions for integration project dependencies (#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
2019-11-26 16:08:32 -08:00
George Kalpakas 7f0d7f4d12 build: update lockfiles for integration projects (#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
2019-11-26 16:08:32 -08:00
Filipe Silva 891708cfc9 build: update to Angular CLI 9.0.0-rc.3 (#33955)
Followup to https://github.com/angular/angular/pull/33337

PR Close #33955
2019-11-21 09:17:18 -08:00
Paul Gschwendtner 15fefdbb8d feat(core): missing-injectable migration should migrate empty object literal providers (#33709)
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
2019-11-18 15:47:20 -08:00
George Kalpakas 74b7d1ace1 test(ngcc): build `zone.js` from source in `scripts/build-packages-dist.sh` (#33733)
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
2019-11-12 09:55:16 -08:00
JiaLiPassion 8c6fb17d29 build: reference zone.js from source directly instead of npm. (#33046)
Close #32482

PR Close #33046
2019-11-06 00:48:34 +00:00
Filipe Silva 02308c4f71 test: update CLI to rc version (#33510)
PR Close #33510
2019-11-01 17:50:56 +00:00
Paul Gschwendtner 4d23b60d09 fix(core): missing-injectable migration should not migrate providers with "useExisting" (#33286)
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
2019-10-25 13:26:00 -07:00
Pete Bacon Darwin d883007cc6 build: update CLI and related dependencies (#33382)
This commit also ensures that the integration tests
are all using the top level dependencies.

Resolves https://github.com/angular/angular/pull/33314#discussion_r338381134

PR Close #33382
2019-10-24 14:12:30 -07:00
Filipe Silva abd2a58c67 test: update Angular CLI deps for integration tests (#32957)
PR Close #32957
2019-10-21 11:27:42 -04:00
Filipe Silva a0d16dcfea test: use @types/node compatible with TS 3.6 (#32946)
PR Close #32946
2019-10-18 13:15:17 -04:00
Igor Minar 86e1e6c082 feat: typescript 3.6 support (#32946)
BREAKING CHANGE: typescript 3.4 and 3.5 are no longer supported, please update to typescript 3.6

Fixes #32380

PR Close #32946
2019-10-18 13:15:16 -04:00
Paul Gschwendtner d1323b5c8f test: improve missing-injectable migration test case in ng-update integration test (#33223)
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
2019-10-17 14:14:28 -04:00
Paul Gschwendtner 06093559a2 test: update angular cli version for ng_update_migrations integration test (#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
2019-10-17 14:14:28 -04:00
Paul Gschwendtner 288e5d894d test: add integration test for undecorated-classes-with-di migration (#32349)
Adds tests for the `undecorated-classes-with-di` migration to the
`ng_update_migrations` integration test.

PR Close #32349
2019-08-29 12:34:44 -07:00
Paul Gschwendtner b48dd52494 test: add integration test for missing-injectable migration (#32349)
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
2019-08-29 12:34:43 -07:00
Paul Gschwendtner 7fb3cc07de build: create integration test for ng-update migrations (#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
2019-08-29 12:34:43 -07:00