Previously we added a browser target for `firefox` into the
dev-infra package. It looks like as part of this change, we
accidentally switched the local web testing target to `firefox`.
Web tests are not commonly run locally as we use Domino and
NodeJS tests for primary development. Sometimes though we intend
to run tests in a browser. This would currently work with Firefox
but not on Windows (as Firefox is a noop there in Bazel).
This commit switches the primary browser back to `chromium`. Also
Firefox has been added as a second browser to web testing targets.
This allows us to reduce browsers in the legacy Saucelabs job. i.e.
not running Chrome and Firefox there. This should increase stability
and speed up the legacy job (+ reduced rate limit for Saucelabs).
PR Close#38435
Previously the instructions were included in the golden files to monitor the frequency and rate of
the instruction API changes for the purpose of understanding the stability of this API (as it was
considered for becoming a public API and deployed to npm via generated code).
This experiment has confirmed that the instruction API is not stable enough to be used as public
API. We've since also came up with an alternative plan to compile libraries with the Ivy compiler
for npm deployment and this plan does not rely on making Ivy instructions public.
For these reasons, I'm removing the instructions from the golden files as it's no longer important
to track them.
The are three instructions that are still being included: `ɵɵdefineInjectable`, `ɵɵinject`, and
`ɵɵInjectableDef`.
These instructions are already generated by the VE compiler to support tree-shakable providers, and
code depending on these instructions is already deployed to npm. For this reason we need to treat
them as public api.
This change also reduces the code review overhead, because changes to public api golden files now
require multiple approvals.
PR Close#38224
We recently reworked our `ng_rollup_bundle` rule to no longer output
ESM5 and to optimize applications properly (previously applications were
not optimized properly due to incorrect build optimizer setup).
This change meant that a lot of symbols have been removed from the
golden correctly. See: fd65958b88
Unfortunately though, a few symbols have been accidentally removed
because they are now part of the bundle as ES2015 classes which the
symbol extractor does not pick up. This commit fixes the symbol
extractor to capture ES2015 classes. We also update the golden to
reflect this change.
PR Close#38093
Adds Firefox as browser to `dev-infra/browsers` with RBE
compatibility. The default Firefox browser is not compatible similar to
the default Chromium version exposed by `rules_webtesting`.
The Angular Components repository will use this browser target as
it enables RBE support. Also it gives us more flexibility about
the Firefox version we test against. The version provided by
`rules_webtesting` is very old and most likely not frequently
updated (based on past experience).
PR Close#38029
Often changelogs are generated from the patch branch and then
cherry-picked into the `CHANGELOG.md` file in `master` for
better access and readability. This is problematic though as
`conventional-changelog` (the tool we use for generating the
changelog), will duplicate commits when a future changelog
is generated from `master` then (i.e. for a new minor release).
This happens because conventional-changelog always generates the
changelog from the latest tag in a given branch to `HEAD`. The
tag in the patch branch does not correspond to any SHA in `master`
so the intersection of commits is not automatically omitted.
We work around this naively (until we have a better tool provided
by dev-infra), by deduping commits that are already part of the
changelog. This has proven to work as expected in the components
repo.
PR Close#37956
Refactors the `ng_rollup_bundle` rule to a macro that relies on
the `@bazel/rollup` package. This means that the rule no longer
deals with custom ESM5 flavour output, but rather only builds
prodmode ES2015 output. This matches the common build output
in Angular projects, and optimizations done in CLI where
ES2015 is the default optimization input.
The motiviation for this change is:
* Not duplicating rollup Bazel rules. Instead leveraging the official
rollup rule.
* Not dealing with a third TS output flavor in Bazel.The ESM5 flavour has the
potential of slowing down local development (as it requires compilation replaying)
* Updating the rule to be aligned with current CLI optimizations.
This also _fixes_ a bug that surfaced in the old rollup bundle rule.
Code that is unused, is not removed properly. The new rule fixes this by
setting the `toplevel` flag. This instructs terser to remove unused
definitions at top-level. This matches the optimization applied in CLI
projects. Notably the CLI doesn't need this flag, as code is always
wrapped by Webpack. Hence, the unused code eliding runs by default.
PR Close#37623
Historically files to be formatted were added to a listing (via matchers)
to be included in formatting. Instead, this change begins efforts to
instead include all files in format enforcement, relying instead on an
opt out methodology.
PR Close#36940
Rename bazel workspace from npm_dev_infra to npm_angular_dev_infra_private to make it clear that this package is private to angular.
Change driver-utilities module_name to match the new bazel workspace name.
Correct a comment by rewording it from "deployed version" to "published version".
Fix merge conflicts in tmpl-package.json
Make "//packages/bazel/src:esm5.bzl" replacement more generalized so that importing from "//packages/bazel" works.
Deleted "dev_infra/*" path from modules/benchmarks tsconfig.
Moved //dev-infra/benchmark/browsers to //dev-infra/browsers.
PR Close#36800
This reverts commit 078b0be4dc.
The original commit was a work around for a bug in CLI. That bug was fixed in the CLI, as a result this change is no longer needed and is being reverted.
PR Close#37074
Remove TypeScript 3.6 and 3.7 support from Angular along with tests that
ensure those TS versions work.
BREAKING CHANGE: typescript 3.6 and 3.7 are no longer supported, please
update to typescript 3.8
PR Close#36329
For testing on IE, shims must be served in es5. Because the shims
served in these tests come from node_modules and are not part of
the angular/angular source code, they must be transpiled to es5 if
they are published as es6. This macro allows for a uniform method
for running this transpilation during the build process.
PR Close#36802
Migrates away from gulp to ng-dev for running our formatter.
Additionally, provides a deprecation warning for any attempted
usage of the previous `gulp format:*` tasks.
PR Close#36726
* Move tools/brotli-cli, tools/browsers, tools/components,
tools/ng_rollup_bundle, and modules/e2e_util to dev-infra/benchmarking
* Fix imports and references to moved folders and files
* Set up BUILD.bazel files for moved folders so they can be packaged with
dev-infra's :npm_package
PR Close#36434
Previously our CI during the setup process has made requests
to the Github API to determine the target branch and shas.
With this change, this information is now determined via git
commands using pipeline parameters from CircleCI.
PR Close#36500
Although this code has been part of Angular 9.x I only noticed this
error when upgrading to Angular 9.1.x because historically the source
locale data was not injected when localizing, but as of
angular/angular-cli#16394 (9.1.0) it is now included. This tipped me off
that my other bundles were not being built properly, and this change
allows me to build a valid ES5 bundle (I have also added a verification
step to my build pipeline to alert me if this error appears again in any
of my bundles).
I found the `locales/global/*.js` file paths being referenced by the
`I18nOptions` in
@angular-devkit/build-angular/src/utils/i18n-options.ts,
and following that it looks like it is actually loaded and used in
@angular-devkit/build-angular/src/utils/process-bundle.ts. I saw the
function `terserMangle` does appear that it is likely aware of the build
being ES5, but I'm not sure why this is not producing a valid ES5
bundle.
This change updates `tools/gulp-tasks/cldr/extract.js` to produce ES5
compliant `locales/global/*.js` and that fixes my issue. However, I am
not sure if @angular-devkit/build-angular should be modified to produce
a valid ES5 bundle instead or if the files could be TypeScript rather
than JavaScript files.
A test that a valid ES5 bundle is produced would be helpful, and I hope
this is reproducible and not some issue with my config.
PR Close#36342
Previously, the bazel stamping regex only matched on versions
0-9 for major and minor numbers, this update allows for matching
on any number for major, minor or patch.
PR Close#36523
Prior to this change we manage a local version of commit message validation
in addition to the commit message validation tool contained in the ng-dev
tooling. By adding the ability to validate a range of commit messages
together, the remaining piece of commit message validation that is in the
local version is replicated.
We use both commands provided by the `ng-dev commit-message` tooling:
- pre-commit-validate: Set to automatically run on an git hook to validate
commits as they are created locally.
- validate-range: Run by CI for every PR, testing that all of the commits
added by the PR are valid when considered together. Ensuring that all
fixups are matched to another commit in the change.
PR Close#36172
Update to clang@1.4.0 to gain support for optional changing and nullish
coalescing. Because this would trigger a change on >1800 files in the
repository, also changes our format enforcement to only be run against
changed files. This will allow us to incramentally roll out the value
add of the upgraded clang format.
PR Close#36203
$(location) is not recommended in the bazel docs as depending on context it will either return the value of $(execpath) or $(rootpath). rules_nodejs now supports $(rootpath) and $(execpath) in templated_args of nodejs_binary.
PR Close#36308
This is done by requesting the refs and shas for the PR when the
env.sh script is run. Additionally, the env.sh script is now setup
to write all of the environment variables created to a cache file
and subsequent loads of the environment load the values from there.
The get-refs-and-shas-for-target.js script now also first attempts
to load the refs and shas from an environment variable before
falling back to requesting from github via the API.
PR Close#36207
The `ng_rollup_bundle` rule currently is only consumed in the
Angular framework repository. This means that Angular packages
are built from source, and ngcc is never needed to build rollup
bundles using Ivy.
Though, this rule is planned to be shared with other repositories
to support common benchmark code. This means that ngcc needs to be
handled as these other repositories cannot build Angular from source,
but instead consume Angular through NPM (with ngcc enabling Ivy).
The `ng_rollup_bundle` rule needs to dynamically prioritize `ngcc`
generated main resolution fields if `--define=angular_ivy_enabled=True`
is set (or with the alias: `--config=ivy`).
ds
PR Close#36044
Currently on Windows, it's not possible to approve goldens in
`ts-api-guardian`. This is because paths are resolved relatively
to the working directory. In Windows, golden files are resolved
to the actual workspace directory. The current logic tries to
compute a relative path to the runfile from the working directory.
This causes the file paths to have a lot of parent directory
path segments. Eventually, when joined with the build workspace
directory, the paths end up being incorrect. e.g.
```
fileName = ../../../../../../projects/angular/golden/<..>/common.d.ts`
outFile = BUILD_WORKSPACE_DIR + fileName;
```
To fix this, we no longer deal with confusing relative paths, but
instead always use absolute file system paths.
Additionally, this fixes that new goldens are generated at the wrong
location on all platforms.
PR Close#36115
Also add two targets to make it more convienent to tail & dump the sauce service logs: //tools/saucelabs:sauce_service_tail & //tools/saucelabs:sauce_service_log
PR Close#36109
The dev-infra package currently uses rollup for packaging. This has been
done initially as a way to workaround manifest paths being used in the
AMD JavaScript output.
The actual solution to this problem is setting module names that match
the `package.json` name. This ensures that the package can be consumed
correctly in Bazel, and through NPM. This allows us to get rid of the
rollup bundling, and we don't need to hard-code which dependencies
should be external or included.
Additionally, tools that are part of `dev-infra` can now specify
their external dependencies simply in the `package.json`. To reduce
version duplication, and out-of-sync versions, a new genrule has been
created that syncs the versions with the top-level project
`package.json`.
PR Close#35647
Creates a tool for validating TypeScript circular dependencies. The tool
has been designed in a way that allows us to slowly burn down the amount
of circular dependencies while ensuring that we don't regress.
The tool doesn't rely on Madge since it doesn't provide a programmatic
way for doing path mapping. We need path mapping since we also want to
check for cycles across different entry-points or packages. The tool
uses the TypeScript AST to manually collect cycles. This code is not
a lot of bloat and also gives us more flexibility (if we ever need it).
Closes#35041.
PR Close#35647
This reverts commit f862536ec4.
Reverted due to test failures that have shown up in the Windows CI Jobs
that don't run on pull requests. A follow-up will be sent that re-adds
the changes w/ fixes for the windows test job.
PR Close#36113
Currently on Windows, it's not possible to approve goldens in
`ts-api-guardian`. This is because paths are resolved relatively
to the working directory. In Windows, golden files are resolved
to the actual workspace directory. The current logic tries to
compute a relative path to the runfile from the working directory.
This causes the file paths to have a lot of parent directory
path segments. Eventually, when joined with the build workspace
directory, the paths end up being incorrect. e.g.
```
fileName = ../../../../../../projects/angular/golden/<..>/common.d.ts`
outFile = BUILD_WORKSPACE_DIR + fileName;
```
To fix this, we no longer deal with confusing relative paths, but
instead always use absolute file system paths.
Additionally, this fixes that new goldens are generated at the wrong
location on all platforms.
PR Close#36096
This has a couple benefits:
- we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong.
- you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform.
- bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies
PR Close#36078
Joey Perrott
Alan Agius
Paul Gschwendtner
Igor Minar
Wagner Maciel
Misko Hevery
Andrew Scott
Greg Magolan
Terence D. Honles
Alex Eagle