In order to be able to use the static-query migration logic within
Google, we need to provide a TSLint rule entry-point that wires up
the schematic logic and provides reporting and automatic fixes.
PR Close#29258
This commit makes the integration test for bazel-schematics more robust
by removing package.json.replace. Instead of replacing the file, the
test script now just overrides Angular packages with the local ones.
This commit also fixes running the test locally by providing default
argument for CI_CHROMEDRIVER_VERSION_ARG.
PR Close#28872
This enabled dts flattening in the final distrubutable package.
Notes:
- For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default.
- This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029
Ref: TOOL-611
PR Close#28588
The `web_workers/images` example is not being tested by any e2e
spec and therefore it's technically not necessary to fix that it uses
external resources, though in order to ensure that the Bazel builds
are hermetic and that we can eventually add e2e specs for the
web_worker/image example, we should avoid any use of external
resources.
We remove the `web-animations` polyfill in the `web_workers/animations`
example because we should try to vendor as few as possible deps. Also
the animations API is already supported by browsers we run the e2e tests
against (note here: `web_workers/animations` is currently also disabled)
PR Close#28562
We currently face a lot of flakiness with our
Saucelabs CI jobs. These randomly exceed the 10min
CircleCI no-output limit because something throws
off `sauce-connect` in a long-lasting loop where
it tries to connect to some of their Saucelabs
servers. The initial assumption from the Saucelabs
team was that we might have some invalid firewall
rules, but this does not answer why this happens
_randomly_, so the latest update from the support
is that there have been some changes in the latest
version of `sauce-connect` version that **could**
cause this flakiness.
I've manually did multiple test runs and was only
able to reproduce the issues with v4.5.3 (latest
version), so it might be worth downgrading to
v4.5.1. This is also what the Saucelabs support
proposed us to do (though it's not guaranteed that
v4.5.1 is unaffected by the same issue)
PR Close#28659
Currently we install `firebase-tools` manually in the
integration tests run script. This is problematic
because it means that we cannot cache `firebase-tools`
properly and Yarn might time out downloading this
dependency. We can safely move this to the top level
`package.json` since Bazel now has a `.bazelignore` and
since we have a cache that works for PRs (with fallback
caching).
Note that the `.bazelignore` is relevant here because
`firebase-tools` has been mainly moved to the bash
script because it broke some Bazel calls.
See 4f0cae0676.
PR Close#28615
Currently our version of Yarn is installed through
the "circleci/node" docker image. This is problematic
because in order to be able to update Yarn, we always
need to update the docker image to a version that
comes with the desired Yarn version. Sometimes there
is no docker image with the desired latest Yarn version,
and therefore we cannot easily update the Yarn version.
Additionally updating the docker image also means that
we need to update our version of NodeJS, as well as the
version of `openssl` might have changed (meaning that
our encrypted credential files may not be decodable with
the new version of `openssl`)
PR Close#28546
Currently all playground examples are built with `tsc`
and served with the `gulp serve` task. In order to be able
to test these examples easily with Ivy, we now build and
serve the examples using Bazel. This allows us to expand our
Ivy test coverage and additionally it allows us to move forward
with the overall Bazel migration. Building & serving individual
examples is now very easy and doesn't involve building everything
inside of `/modules`.
PR Close#28490
By default, `webdriver-manager update` will download the latest
ChromeDriver version, which might not be compatible with the Chrome
version included in the [docker image used on CI], causing CI failures.
Previously, we used to pin the ChromeDriver version on CI in
[ngcontainer's Dockerfile][2]. This was accidentally broken in #26691,
while moving from ngcontainer to default CircleCI docker images.
This commit fixes the issue by pinning ChromeDriver to a known
compatible version.
[1]: bfd48d156d/.circleci/config.yml (L16)
[2]: bfd48d156d/tools/ngcontainer/Dockerfile (L63)
PR Close#28494
This lets us run ngtsc under the tsc_wrapped custom compiler (Used in Bazel)
It also allows others to simply wire ngtsc into an existing typescript compilation binary
PR Close#28435
This lets us run ngtsc under the tsc_wrapped custom compiler (Used in Bazel)
It also allows others to simply wire ngtsc into an existing typescript compilation binary
PR Close#28431
This lets us run ngtsc under the tsc_wrapped custom compiler (Used in Bazel)
It also allows others to simply wire ngtsc into an existing typescript compilation binary
PR Close#27806
Greg Magolan
Matias Niemelä
Alex Eagle
Paul Gschwendtner
Igor Minar
Kara Erickson
Keen Yee Liau
Andrew Kushnir
Alan
Wassim Chegham
Ben Lesh
George Kalpakas
Adam Plumer
Miško Hevery
Filipe Silva
Jason Aden
jithil-kore