To increase the ease of development we are moving @angular/docs into the adev directory within this repo. While
we are doing this to improve our development experience in the short term, efforts are also in place
to maintain a division between this @angular/docs (shared) code and adev itself, so that it can be extracted
back out in the future when components is ready to leverage it as well.
PR Close#57132
The saucelabs connect tunnel utility is now downloaded via bazel as needed.
For the directly invoked case the utility is downloaded via the local shell script.
Previously it was part of the root `package.json` and downloaded whenever
a package install was executed. The utility archive was also not an actual
package which incidentally worked with npm but does not work with newer versions
of yarn.
PR Close#56456
Similar to what we did for aio, we should not clear the architect CLI
output in Bazel. This messes up with the output and makes debugging
hard.
PR Close#55282
I initially tried switching to use public entry points under `zone.js/plugins/*`, however this file is both manually compiled for Saucelabs and also built with Bazel for a number of tests. The Bazel integration doesn't work well with depending on real NPM packages, so importing `zone.js/plugins/*` in that context doesn't really work. Instead we need to depend on the internals and manually call the `patch*` functions.
PR Close#53443
Adds infrastructure to run signal input tests with JIT (using the
transform) and AOT. Acceptance tests for signal inputs will run with
both variants. In the future we can consider expanding this
infrastructure for all of our acceptance tests, but that's a different
story.
PR Close#53808
This commit adds a transform for supporting input signals in JIT
environments. The transform will be wired up for Angular CLI
applications automatically. An integration test verifies that this fixes
unit testing with signal inputs.
The transform basically will take the signal input metadata and
transform it into `@Input` decorators that can provide static
information to the Angular JIT runtime when the directive/component
definition is compiled.
PR Close#53808
The `multimatch` package was only used in the saucelabs test bundling
script to filter out spec files that should be ignored during saucelabs
testing. This functionality can be replaced with `fast-glob` package's
`ignore` option. This removes the need for the `multimatch` package within
the repository.
PR Close#53463
The repository currently has two globbing packages. To minimize the number of packages in
the framework repository, the uses of the `glob` package are being converted
to `fast-glob` which is used by the tooling repository. The change is mostly mechanical
and in this change the build and test scripts are converted.
PR Close#53397
These patches are no longer necessary with the current state of the
type packages and the code within the repository. The types are now
included in the already required babel.d.ts file for the relevant
babel packages (currently: `@babel/core` and `@babel/generator`).
PR Close#53441
These patches are no longer necessary with the current state of the
type packages and the code within the repository. The types are now
included in the already required babel.d.ts file for the relevant
babel packages (currently: `@babel/core` and `@babel/generator`).
PR Close#53374
Adds build rules for "artificially" generating `DocEntry` collections for block and element APIs. The two rules are very similar, but _just_ different enough that it's worth having two separate implementations.
PR Close#52480
This adds a target to generate a manifest of all public api symbols. The majority of inputs are generated from the extraction rules, but API entries that don't have a TypeScript source symbol (elements and blocks) are defined in hand-written json collections.
PR Close#52472
This adds `generate_api_docs` targets to all of the packages for which we publish api reference docs. One known issue here is that any type information that comes from another package (e.g. router depending on core) currently resolve to `any` because the other sources are not available in the program. This can be tackled in a follow-up commit.
This commit also updates the install patch for `@angular/build-tools` to use the local version of compiler-cli.
PR Close#52034
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
This is needed to better support native ESM modules and avoid the otherwise necessary deep imports like `zone.js/fesm2015/zone-node.js` due to disallowed directory imports.
PR Close#51652
We temporarily enable video recording for Saucelabs bazel tests. We are
seeing some flakiness here, and before we can replace the legacy job,
we should understand why the browsers sometimes disconnect.
PR Close#51533
Saucelabs seemingly has increased the maximum idle timeout. So we
leverage that to improve stability of our tests. Useful when e.g.
the heartbeat webdriver commands are for some reasons delayed.
PR Close#51533
We still seem to be having Gulp installed for the ZoneJS changelog
generation. Arguably this can be replaced with a simpler JS script,
but in either case, this commit removes an unused file from the old
Gulp task setup.
PR Close#50428
This commit patches `ts_library` to be able to produce `ES2022`. Also, updates the build tsconfig and sets `useDefineForClassFields` to `false` to keep the same behaviour of `ng_module`.
PR Close#49559
This commit patches `ts_library` to be able to produce `ES2022`. Also, updates the build tsconfig and sets `useDefineForClassFields` to `false` to keep the same behaviour of `ng_module`.
PR Close#49332
The decorator downlevel transform is never used for actual class
decorators because Angular class decorators rely on immediate execution
for JIT. Initially we also supported downleveling of class decorators
for View Engine library output, but libraries are shipped using partial
compilation output and are not using this transform anymore.
The transform is exclusively used for JIT processing, commonly for
test files to help ease temporal dead-zone/forward-ref issues. We can
remove the class decorator downlevel logic to remove technical debt.
PR Close#49351
This commit does three things that all related and required to get
rid of `webdriver-manager`:
* Our puppeteer protractor setup in AIO relies on webdriver-manager
because we install a corresponding chromedriver based on the puppeteer
chromium version. We would like to get rid of this brittle setup.
* We don't use `puppeteer` in many places because we manage chromium and
the driver through Bazel. This commit removes the remaining puppeteer
usage and replaces it with the Bazel-managed canonical browser
* We need to migrate the AIO production URL tests to Bazel. These
weren't part of Aspect's migration. This is needed so that we can drop
puppeteer and use the Bazel browser setup.
* Migrates some at-runtime TS `ts-node` test setup to proper idiomatic
Bazel code. Needed because it depends on code that also had to be
migrated to Bazel given the production e2e test Bazel migration (above
points).
Note: The xregexp dependency had to be added to the root project because
`ts_library` does not support compilation deps from `@aio_npm`. This is
something we will fix anyway when we have a more modern toolchain!
PR Close#49025
* updates ng-dev and build-tooling since the previous SHAs are
no longer existent after the CircleCI incident snapshot build removal.
* accounts for the new stamping variables.
PR Close#48731
The Karma Saucelabs script for Bazel & Saucelabs relies on some CommonJS
specific features. This commit replaces it with an ESM-compatible
alternative so that it can execute because `nodejs_binary` requires ESM
files now.
PR Close#48573
With the recent ESM changes we also started generating Saucelabs
targets for `//devtools` (as part of an effort to avoid code
duplication). We should skip Saucelabs targets for this package
because we don't intend to run them on Saucelabs and this whole
setup needs some more work (and we shouldn't change unexpectedly).
PR Close#48554
Fixes that we temporarily broke the Bazel npm package artifact as
part of the ESM work. This commit adjusts it and also makes the
artifact subsitutions more maintainable.
PR Close#48521
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
* Switches all remaining targets (even if not tested and failing as per
build) away from `ts_devserver` to the canonical `http_server` from
dev-infra.
PR Close#48521
ZoneJS is no longer loaded as an UMD, but instead is included as part
of the browser init entry-point. This means that ZoneJS is bundled and
the ESBuild logic needs to be adjusted for that.
PR Close#48521
* The benchmark macro should also use devmode ESM 2020. No CommonJS
* The benchmark macro should always add `benchpress` as runtime
dependency because it is loaded asynchronously.
* The protractor `nodejs_binary` should use our ESM-interop binary
so that ESM resolution works (e.g. when `await import(benchpress)` from
the driver utilities is invoked).
PR Close#48521
* The Karma Bazel Saucelabs binary needs to use `.mjs` as everything in
the repo w/Bazel is supposed to be ESM.
* The symbol extractor test is updated to no longer use CommonJS
features like `require.resolve`.
PR Close#48521
Since the `defaults.bzl` repo-wide macros are now supporting ESM,
the special spec-bundle logic from `devtools` can be removed.
Also the esbuild configurations need to be updated to account
for the recent dev-infra build-tooling changes. Also properly
now ensures that `aysnc/await` is downleveled for ZoneJS compatibility.
PR Close#48521
* Updates build-tooling to benefit from the latest `spec_bundle`
improvements.
* Updates the ESM extension loader to not attempt adding extensions to
builtin `node:` specifiers. This seems to be disallowed and cannot be
handled gracefully (the attempts are part of a try/catch).
```
Use --sandbox_debug to see verbose messages from the sandbox
Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:fs.mjs
at new NodeError (node:internal/errors:371:5)
at ESMLoader.builtinStrategy (node:internal/modules/esm/translators:276:11)
at ESMLoader.moduleProvider (node:internal/modules/esm/loader:236:14)
```
PR Close#48521
Since the Bazel setup in this repo will now always use ESM,
the tooling scripts/binaries in AIO need to be switched to ESM
too. Most of the scripts are already ESM, but a few had to be converted.
Note that the Dgeni generation does not use ESM because it's unaffected
and the Dgeni CLI is used. In the future we could also update the Dgeni
setup to ESM but there is no need currently.
PR Close#48521
Even with patched resolution, we should always attempt the next/builtin
NodeJS resolution first. It may find a module if there `node_modules`
relative to the context file. This would be more correct than looking
for a module always at the Bazel `npm` repository `node_modules` folder.
PR Close#48521
ESBuild relies on the linker and we currently set up the ESM loader,
along with accidentally enabling the patched resolution loader. This
didn't cause any problems in sandbox, but outside of sandbox incorrect
ESBuild versions may be discovered because the loader looks at the
top-level `npm/` node modules before looking relative to e.g.
`@bazel/esbuild`
PR Close#48521
* Adjusts tests to no longer rely on CommonJS features. Switches them to
ESM
* Updates test initialization files to not double-initialize Jasmine now
that bootstrap files are loaded after Jasmine. The `jasmine.boot`
setup was hacky from `rules_nodejs` and will break in the future
regardless if we e.g. use `rules_js` with actual unmodified `jasmine`.
PR Close#48521
Protractor does not support ESM, so we need to take all the ESM
output and bundle it into a CommonJS file. This comes at the cost
of not using actual ESM for execution, but the ESBuild bundle follows
strict ESM semantics so we can be sure it's compatible when we have
an ESM-compatible e2e test runner in the future.
PR Close#48521
There are two build targets which never had all its runtime dependencies
properly specified. This wasn't noticed because there were macros in
`defaults.bzl` that automatically included these deps.
In a follow-up we will clean-up this legacy auto-deps feature in
`defaults.bzl`.
PR Close#48521
Introduces a variant of `jasmine_node_test` that works with async/await
in combination with ZoneJS. This is needed for tests relying on
async/await in combinatin with change detection.
Browser tests are already benefting from ESbuild async-await
downleveling. Node tests would ideally not need this, but until
ZoneJS supports native async/await we need to also process
source files to avoid native async/await syntax.
PR Close#48521
The Angular CLI does not yet support schematics running as ESM. For
this reason we switch the schematics BUILD targets to explicitly
use ESM (as an exception in the repo).
PR Close#48521
Since Karma with Bazel does not support ESM natively, we bundle the
tests using ESBuild into a single AMD file. This not only solves the
ESM issue until we can run browser ESM tests natively (also pending
in the components repo - the esbuild generation follows ESM semantics
but since collapsed we don't rely on the real module system).
A benefit of bundling is also faster and more reliable Karma browser
tests since only a single file needs to be loaded- compared to hundreds
of individual files.
PR Close#48521
Update dev-infra's build-tooling since multiple ESM changes have
landed there. e.g. not relying on `require.main === module` for API
bundling. This will allow us to also execute all dev-infra rules
in ESM because we plan on applying our ESM patching to `ts_library`
(which would also affect build-tooling then).
PR Close#48521
We use `bazel/esbuild` in various places (e.g. for app bundling tests).
These tests rely on the Angular Compiler-CLI itself for e.g. linking
or the Terser configuration. Since everything in this repo is now
strict ESM, the ESBuild configs (which are already ESM-supported)
need to import from `//packages/compiler-cli`. We also need to be
able to leverage our existing ESM Bazel loader for this though as
otherwise resolution would fail.
Long-term we can remove this if everything in the compiler-cli
would use `.mjs` extensions and the import paths would also specify
an explicit extension. See: https://nodejs.org/api/esm.html#mandatory-file-extensions
PR Close#48521
The ESM loader when used with patched Bazel module resolution
handled subpaths incorrectly. e.g.
`@bazel/concatjs/tsc_wrapped/internal/index.js` could be incorrectly
resolved to `@bazel/concatjs/index.js`.
This commit fixes the flawed logic. Also we prioritize the ESM attempts
before the original specifier. This is necessary because otherwise
the default Node resolution (using `require.resolve`) may incorrectly
prefer the `index.js` file over a `index.mjs` when a directory is
imported.
PR Close#48521
Since we no properly initialize as part of the spec-entrypoint
the hacky logic starting Jasmine can be removed. The init
file now runs before tests run, but after Jasmine is initialized.
Calling `boot` while Jasmine is already initialized results in
tests executing in a different context and before other
initialization work completes.
PR Close#48521
Since we generate a `.mjs` file as entry-point for jasmine tests,
a couple of issues prevented the transitive dependencies from
bootstrap targets to be brought in (causing resolution errors):
1. The `_files` (previously `_esm2015`) targets are no longer needed,
and they also miss all the information on runfiles.
2. The aspect for computing linker mappings does not respect the
`bootstrap` attribute from the `spec_entrypoint` so we manually
add the extract ESM output targets (this rule works with the aspect
and forwards linker mappings).
PR Close#48521
RxJS currently ships ESM output that cannot be executed directly
in NodeJS. This is because RxJS ships ESM as `.js` files but does
not have a `package.json` which instructs Node to execute these as ESM.
RxJS would either need to use the explicit `.mjs` extension, or add
a `type: module` `package.json` next to the `.js` sources.
We manually patch RxJS to do this, while we wait on the upstream fix
to land. See: #7130.
PR Close#48521
The prodmode compilation pipeline -that we intend to use more heavily
now given it emitting files with the `.mjs` extension- exposes an
additional tsickle closure externs file. This file is empty most
of the time anyway since tsickle is not wired up.
We remove this generation as otherwise convenient `$(location` of
such ts library targets break because there always is more than 1 file.
PR Close#48521
Note: `--require` does not work for ESM. `--import` does not exist
in the current Node versions. Started being available in NodeJS v19.
A custom entry-point script, already supported by dev-infra, simplifies
the whole logic and solves the ESM case.
PR Close#48521
For every `ts_library` target we expose a shorthand that grants
access to the JS files because `DefaultInfo` of a ts library
only exposes the `.d.ts` files.
We rename this away from `es2015` since in practice it's a much
higher target these days. Additionally we no longer use the devmode
output but rather use the prodmode output which has the explicit
`.mjs` output- compatible with ESM.
PR Close#48521
We introduced a loader that supports ESM with Bazel. This loader can
only be enabled as part of our `nodejs_binary` defaults.bzl test. This
works fine, but there might be other binaries/tests e.g. from
`@angular/build-tooling` that should be able to use ESM & might need to
for importing the `compiler-cli`.
We move the logic for installing the patch into a `rules_nodejs` patch.
There is an existing one that is just updated to "enable ESM support".
PR Close#48521
This is necessary for e.g. JSON files from the CLDR data repository.
Otherwise these could not be added to the runfiles of the
binaries/tests.
PR Close#48521
For the ESM interop patches we expect to have two types
of patches:
* Patches for `node_modules`
* Patches for Bazel repositories.
We move the patches in respective folders to make it very clear
where a patch is used/applied to.
PR Close#48521
We modified the macros of `nodejs_binary/test` to have a rule
in between that requests the `.mjs` output. This works fine but
breaks make variable substitution for `templated_args` because
Bazel requires referenced labels to be part of the explicit `data`.
The rule in between breaks this, so we add a new argument that
can be used for such "template"/"args" data dependencies.
This can be removed when everything is ESM and we don't need
the rule in between.
PR Close#48521
The `nodejs_binary` rule already prioritizes the `.mjs` output as
of the recent commits. The `nodejs_test` rule should do the same,
and also set `use_esm = True`
PR Close#48521
The Bazel NodeJS rules will always use the `.js` files as entry-points.
Since we only rely on the `.mjs` output going-forward, we need to teach
`nodejs_binary` and `nodejs_test` to use the `.mjs` extensions if
intended.
Our `defaults.bzl` macros will set `use_esm = True`, but other targets
from e.g. external repositories should keep the original behavior.
PR Close#48521
Replaces the existing ESM loader for dealing with external module
imports. This loader was introduced by Aspect for AIO `.mjs` scripts.
The loader will be used as foundation for a more extensive loader
that also properly handles first-party packages.
Additionally another loader is added, all packed as a single
loader because our current NodeJS version only supports a single
loader per node invocation. So we implement chaining ourselves.
The new loader will attempt rewriting `.js` extensions to `.mjs`,
also it will add `.mjs` if not already done. This is necessary
in the transition phase because we don't/cannot use explicit `.mts`
extensions and also we don't specify extensions in imports yet.
Long-term we would likely use `.mts` and explicit import extensions,
but it's not yet clear how we would sync this into g3 too.
PR Close#48521
This is in prearation for having a proper diff when this loader
is adjusted to support more situations than just simple external
node modules. See next commit.
Also the file is formatted to make the diff less verbose later.
The file was never formatted correctly and we don't lint `.mjs` files.
PR Close#48521
Currently the devmode output for `ng_module` and `ts_library` is
using ES5 CommonJS UMD. To bring it in sync with prodmode and
to start with our long-term migration to full ESM- the devmode
is updated to to ES2020 ES modules too.
This will require more tricks to make devmod work with the bazel
setup and also tests may need to be refactored given them relying
on ES5 CJS features, like for `spyOn` jasmine patching etc.
PR Close#48521
Similar to the Rules NodeJS require patch, we have an ESM import patch
as of the AIO Bazel migration (to support ESM scripts better).
This script uses `--loader`, an experimental NodeJS flag. This is
similar to how `ts-node` uses it. We should disable the warnings
as it results in a lot of unreadable Bazel output and the warnings
are okay to be ignored. Note that we cannot fine-grain disable
the specific warning so all others would be disabled too.
Realistically we haven't seen any in the past and long-term we will
be not relying on patched resolution anyway (looking at `rules_js`).
PR Close#48282
Temporary patch until
https://github.com/bazelbuild/rules_nodejs/pull/3517 is available in
another `rules_nodejs` release.
We can remove this patch, but for now it doesn't hurt. On the external
side the tsickle code path is not hit at all anyway, but we need to
satisfy the TypeScript checker.
PR Close#47018
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
The JS size-tracking logic has been moved into the dev-infra repository
and the rule has been updated to work better with Bazel labels. The
Starlark target is updated accordingly in this commit.
PR Close#46802
This script was used back when dev-infra code was part of
the Angular framework repository. The script is now unused
and can be deleted.
PR Close#46798
The jasmine seed generator is only used in a single karma configuration
file. Used by the legacy build and the Saucelabs/ZoneJS Karma jobs.
We should move the separate script code directly into the config to make
it clear that the seed generation is not used elsewhere, and to simplify
the Starlark code.
PR Close#46798
The `app_bundle` rule from the shared dev-infra package is no longer in
the benchmarking folder, but instead is part of the general Bazel rules
exposed by `dev-infra`. This commit accounts for this location change.
PR Close#46642
tsec previously did not use runfiles on Windows even when the flag was enabled.
The latest version now adds an option to force its usage.
PR Close#46447
Patches are required for tsec and rules_webtesting. The fix for
rules_webtesting was merged to that repo
(581b1557e3)
but it's unclear when a release will be cut.
PR Close#46313
The NodeJS Bazel linker does not work well on Windows because there
is no sandboxing and linker processes from different tests will attempt
to modify the same `node_modules`, causing concurrency race conditions
and resulting in flakiness.
PR Close#45872
Speeds up the dev-turnaround by only bundling types when packaging. Currently
bundling occurs for all the `ng_module` targets in devmode.
This has various positive benefits:
* Avoidance of this rather slower operation in development
* Makes APF-built packages also handle types for `ts_library` targets consistently.
* Allows us to ensure APF entry-points have `d.ts` _always_ bundled (working with ESM
module resolution in TypeScript -- currently experimental)
* Allows us to remove the secondary `package.json` files from APF (maybe APF v14? - seems
low-impact). This would clean-up the APF even more and fix resolution issues (like in Vite)
PR Close#45405
As part of the devtools migration, we copied the custom http server/
dev-server from the `angular/components` repo. This server implementation
has now moved to the shared dev-infra code, and we can clean up the
copy in this repository now.
PR Close#45452
As mentioned in previous commits (check them for more details), `@bazel/typescript`
no longer contains `ts_library`-specific code, so we no longer need that dependency.
PR Close#45431
Update `@bazel` packages to the latest 5.x version.
Some of the changes here are modeled after
angular/dev-infra@40c0ac8559.
Co-Authored-By: George Kalpakas <kalpakas.g@gmail.com>
PR Close#45431
Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
PR Close#45286
Switches the Karma web test rule from `@bazel/concatjs` to our
wrapped/extended variant from the shared dev-infra code.
One benefit is that we now get a `_debug` target for web tests where
no browser is being launched and the action is kept alive. Allowing
developers to conveniently connect a browser manually for debugging.
Also works with iBazel for the manually connected browser.
PR Close#45117
Previously with ESBuild 0.14.11, when a file had dynamic requires to
builtin NodeJS modules like `url`, the resolution completed successfully
regardless of `--platform browser`. This seems to be fixed in ESBuild now.
This unveiled some resolution errors with our Saucelabs bundle generation
because the framework code sometimes switches dynamically to `require('url')`
if `window.URL` is not defined. Previously this just didn't matter, but now
the `require('url')` is checked and a module resolution error is reported given
`url` not being available in the browser as a builtin module.
We fix this by marking the module as external. We will not hit this code path
anyway in the browser saucelabs code. Similarly we exclude all platform-server
files from the bundle. This is not strictly needed after the `url` module being
marked as external, but the issue showed that lots of unnecessary code for the
server platform is included. This can be omitted (unfortunately not from the TS
compilation without over-complicating things significantly more; experimented with
that).
PR Close#44830
Updates the postinstall patch for the benchmark macro rule from dev-infra.
We moved the ZoneJS setup to the bundler. This was necessary in order to
switch away from the Go-based (windows-incompatible, m1-incompatible)
concatjs devserver to a rather basic HTTP server (also provided by dev-infra now).
PR Close#44830
Previously devtools used a nested workspace for its bazel configurations. This meant framework dependencies were consumed via npm.
Now devtools is part of the root bazel directory that all other files in this codebase fall under. This allows us to build devtools using local angular packages, removing the need to consume these dependencies with npn. This is useful because we no longer have to update these dependencies with an automated tool like renovate, and our CI tests will always run against the most up to date framework packages.
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
The `ng_rollup_bundle` rule has been replaced with a new rule called
`app_bundle`. This rule replicates the Angular v13 optimization
pipeline in the CLI, so that we can get better benchmarking results.
Also the rule is much simpler to maintain as it relies on ESbuild.
The old `ng_rollup_bundle` rule did rely on e.g. build-optimizer that no
longer has an effect on v13 Angular packages, so technically size
tests/symbol tests were no longer as correct as they were before. This
commit fixes that.
A couple of different changes and their explanation:
* Language-service will no longer use the benchmark rule for creating
its NPM bundles! It will use plain `rollup_bundle`. ESBuild would have
been nice but the language-service relies on AMD that ESBuild cannot
generate (yet?)
* Service-worker ngsw-worker.js file was generated using the benchmark
bundle rule. This is wrong. We will use a simple ESbuild rule in the
future. The output is more predictable that way, and we can have a
clear use of the benchmark bundle rule..
* A couple of benchmarks in `modules/` had to be updated to use e.g.
`initTableUtils` calls. This is done because with the new rule, all
files except for the entry-point are considered side-effect free. The
utilities for benchmarks relied on side-effects in some
transitively-loaded file (bad practice anyway IMO). We are now
initializing the utilities using a proper init function that is
exported...
PR Close#44490
We are in an inconvenient situation where the ng-dev package might rely
on packages from the Angular framework repository. Given that we install
this package in the framework repository, we need to update some
references through a postinstall.
This commit updates the patches to account for the latest changes in the
dev-infra package/repository.
PR Close#44490
Adds the postinstall script as runfile for the `yarn_install`
repository rule, so that the dependencies are re-fetched when
the script changes.
PR Close#44490
Updates the symbol extractor to support IIFE bundles using
arrow-functions instead of function declarations. This is in preparation
for running symbol extraction tests with the overhauled optimization
pipeline for Angular v13, relying on ESBuild internally.
Also removes rollup-specific code that does not seem to be relevant
anymore / rollup will be replaced anyway.
PR Close#44490
Wires up the integration test rule from the shared dev-infra package,
while also deleting the old integration test rule.
The readme is updated to reflect the changes that are being made
to run with the new integration rule. Overall one major difference is
that we will declare the integration test targets within each test
directory, making those actual bazel packages. This is more idiomatic
within Bazel and also reduces the computation within Skyframe as less
globs need to be evaluated for example.
PR Close#44238
Fixes lint errors in the build-saucelabs legacy script. Likely this only
surfaces now after merge due to some other lint-affecting changes
landing just before the script landed.
PR Close#44311
Previously, when we did not bundle tests, we also had the jasmine
default timeout increased to 15000ms. This commit re-introduces this
increased timeout by also maintaining a custom test init file for the
legacy saucelab jobs. This is desirable as all of the Saucelabs test
code is local in the `tools/legacy-saucelabs` folder.
PR Close#44281
Bundle spec files similar to how it is done within the Angular
Components repo. This should simplify the setup and also speed
up the Saucelab job as only a single spec bundle would need to be
downloaded, compared to having to load hundreds of files through the
Saucelabs tunnel.
Also makes a couple of tests more robust with the emulators/and accounts
for ES2015 test runner changes. The tests should be less reluctant to
such build process changes.
Note for reviewers: Some imports have been simplified here. This work
came from Joey's original WIP for this. It's unclear to me whether this
is still needed, but it sounded like this was necessary for the ESBuild
bundling to work. I have robusted the module resolution plugin though,
so I doubt it's still needed. At the same time though: Not worth
reverting/trying as these changes are nice to have anyway!
Co-Authored-By: Joey Perrott <josephperrott@gmail.com>
Co-Authored-By: Paul Gschwendtner <paulgschwendtner@gmail.com>
PR Close#44281
This commit removes most tests that were designated as only covering View
Engine code. It also removes tag filters from CI and local commands to run
tests.
In a few cases (such as with the packages/compiler tests), this tag was
improperly applied, and certain test cases have been added back running in
Ivy mode.
This commit also empties `@angular/compiler/testing` as it is no longer
necessary (this is safe since compiler packages are not public API). It can
be deleted in the future.
PR Close#43884
The API of the `extract_js_module_output` rule has changed with the
latest build of the shared dev-infra package. This commit adds the
missing attributes to the targets using this rule, avoiding the
CI failures as these attributes are mandatory.
Note: For NPM packages the linker mappings are not relevant, neither
do we want to include sources from the external NPM packages inside
those.
PR Close#44145
Contents of generated tsconfig for tsec_test now depend on whether
Bazel uses symlinked runfiles for nodejs_test. The current
implementation assumes that symlinked runfiles are not available
on Windows.
PR Close#43924
Using the tag "view-engine-only" better describes the expected usage of bazel targets with the test. They can
only be run with view engine.
PR Close#43862
Setting the angular_ivy_enabled environment variable to True will default Bazel builds to use the Ivy
compiler rather than defaulting to ViewEngine.
PR Close#43862
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
Enables the `esModuleInterop` for all TypeScript compilations in the
project. This allows us to emit proper ESM-compatible code. e.g.
consider the following import:
```ts
import * as ts from 'typescript';
```
This import currently will break at runtime in NodeJS because the
`typescript` package is not shipping ESM. It's still a CommonJS module.
ES modules are able to import from `typescript` though, using an import
statement as above, but everything in `module.exports` is being exposed
as the `default` named export. TypeScript at runtime does not have any
other named exports, so for actual ESM compatibility, all of our imports
need to be switched to:
```
import ts from 'typescript';
```
The `esModuleInterop` option allows this to work even though the
`d.ts` file of TS currently suggests that there are _only_ named exports.
The TypeScript language service will now suggest the correct import form as
shown above. It doesn't enforce that unfortunately, but this commit also
adds a lint rule that enforces certain patterns so that we emit imports
that are compatible with both ESM and CJS output (CJS still needed here
since tests run with CJS devmode output still; this is a future project
to switch that over to ESM!)
PR Close#43431
This wires up the `@angular/localize/tools` entry-point. For context:
This entry-point is being created to avoid deep imports into
`@angular/localize/src/tools/<..>` like the CLI relies on. Deep imports
do not play well with strict ESM, and now that all APF packages are
strict ESM, the tool code needs to be either strict ESM as well.
We use ESBuild to create individual bundles for the CLI entry-points,
and the actual tool entry-point. We use a bundler because this enables
the localize code be ESM compatible. Without a bundler, all relative imports
within the `tools` entry-point would need to explicitly have the `.js`
extension. This would be cumbersome and hard to maintain/enforce or
validate.
One might wonder why this is not a standard APF entry-point then. The
answer is that the APF entry-points do not support exposing the CLI
binaries (like `yarn localize-translate`). This could be done through
tertiary entry-points, but using ESBuild directly gives us more control
for now. We might want to revisit this in the future again.
PR Close#43431
Similar to other code that is shipped as part of `@angular/common`
(with APF v13), we should ship the generated locale files as ESM
files as well. This is necessary/reasonable because we explicitly
set `type: "module"` for the common package, so it makes sense to
have the same apply for the locale sub-directory.
Note: The global locale scripts remain having the `.js` extension
and will continue to be unmodified. They are CJS/ESM compatible either
way, but refer to browser globals.
PR Close#43431
The bazel integration tests are currently not compatible with Windows.
Tests never get to run because the created tar packages for NPM packages
are built using an outdated `pkg_tar` rule that creates invalid
tarballs. We fix this by using the non-deprecated windows-compatible
`rules_pkg` implementation.
Additionally, we copy all `package.json` files of integration tests to
the bazel bin directory as otherwise the file would be accidentally
modified as a source on Windows.
PR Close#43431
Technically this change would not be needed as the NPM package
output is always built with Ivy now (using the transition). There
is no View Engine output anymore. We still want to limit the tests
to only run with the `--config=ivy` define setting as some API goldens
tests could accidentally rely on plain `ng_module` output / additionally
we wouldn't need to run the API golden tests multiple times.
PR Close#43431
For APF v13, terser has been updated to v5, and the prodmode output
has changed from ES2015 to ES2020. This results in some changes in
the symbol extractor test. Here are the two causes of changes:
* As said in the previous commit, Terser drops the initializer for
variables which are set to `undefined`. We have updated the symbol
extractor to always capture such declarations w/o initializer now.
This means that a couple of declarations that a couple of new
symbols are captured now. These previously didn't have an initializer
even without Terser, and just didn't show up before.
* Terser changed its inline mechanism for functions that recursively
call themselves. Such functions are no longer inlined and therefore
show up in goldens now.
PR Close#43431
Updates the symbol extractor test to work with Terser v5 that
drops the variable declaration initializer if it is explicitly set
to `undefined`. We want to capture such identifiers in the bundles
as otherwise the majority of top-level declarations which are intially
set to `undefined` would be hidden in size goldens.
PR Close#43431
With the changes to support APF v13 in the `ng_package` rule, we have
removed the ambiguous `entry_point` attribute. The attribute suggested
that it would be used for determining the primary entry-point input
file. This was not the case as the flat module output file is consulted
for bundling et at. The attribute has been renamed to match its
purposed (renamed to `primary_bundle_name`).
We no longer need to set that attribute because the primary bundle
name is (1) not of relevance for consumers and (2) the rule already
infers the bundle name properly from the Bazel package.
PR Close#43431
This commit implements partial compilation APF v13 for the
`ng_package` rule. The changes involve the following things:
1. Requesting the partial compilation output for all targets (and
its transitives) in the `deps` or `srcs` attributes.
2. Downleveling of ES2020 prodmode output to a FESM2015 file.
3. Cleanup of file resolution. Previusly, execroot file paths (which are
passed to the packager tool) were composed manually. This is prone to
mistakes and breaks with transitions.
A lot of this code can be simplified by passing the necessary Bazel
`File` information as JSON. This also simplifies the packager tool
significantly (and makes it more readable..)
4. Remoal of UMD bundles. This also allows us remove the `globals` rule
attribute with `externals` (we do not need any UMD global identifier
names anymore).
5. The `package.json` will set the `exports` field and use subpath
exports to make module resolution work for ESM consumers.
6. TSLib is also always set as `external` now. Previously it had to be
added as `dep` to the `ng_package` rule as UMD files bundled `tslib`.
7. The `include_devmode_srcs` option has been removed. This option was
an addition to APF that allowed the `@angular/compiler` to ship
non-flattened ES5 CommonJS sources. We want to keep APF consistent
and not allow such exceptions. Compiler is now a strict APF package
as well, and the compiler-cli just needs to go through the primary
entry-point for things it needs (or it bundles the necessary parts
into the CLI.)
Overall, these are all changes. A lot of changes to make the packager
rule and tool more readable and Bazel-idiomatic were made as well. This
allows us to easier make packaging changes in the future, and it's more
future-proof if we ever change how inputs (like `ng_module` targets) are
generated (e.g. consider a case where we'd use the `ts_project` rule).
PR Close#43431
Previously, the prodmode output was using ES2015 for `ng_module` and
`ts_library` targets. This commit changes it to `ES2020`. This is
necessary as we want to ship es2020 output in APF v13.
PR Close#43431
This is to replace the implicitly created ts_library_forwared rules and
keep changes related to tsec/bazel integration solely in tools/tsec.bzl.
PR Close#43108
Introduce two new bazel rules: tsec_test and tsec_config, for
describing the tsec checks and the tsconfig file needed for such
checks, respectively. Currently, tsec_test only checks the srcs
of a ts_library or ng_module. It does not check direct or transitive
dependencies. Also, tsconfig files need to be manually maintained
to make sure tsec can read all necessary input (including global
symbols).
PR Close#43108
This commit removes `ts-api-guardian` from the repository. We introduced
a new tool for testing API signature that is part of the shared
dev-infra package. The TS API guardian package will be deprecated for
the public in favor of Microsoft's API extractor that has support for
more parts of the syntax, such as alias exports.
PR Close#42735
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
In combination with the TS `noImplicitOverride` compatibility changes,
we also want to follow the best-practice of adding `override` to
members which are implemented as part of abstract classes. This
commit fixes all instances which will be flagged as part of the
custom `no-implicit-override-abstract` TSLint rule.
PR Close#42512
TypeScript introduced a new flag called `noImplicitOverride` as part
of TypeScript v4.3. This flag introduces a new keyword called `override`
that can be applied to members which override declarations from a base
class. This helps with code health as TS will report an error if e.g.
the base class changes the method name but the override would still
have the old method name. Similarly, if the base class removes the method
completely, TS would complain that the memeber with `override` no longer
overrides any method.
A similar concept applies to abstract methods, with the exception that
TypeScript's builtin `noImplicitOverride` option does not flag members
which are implemented as part of an abstract class. We want to enforce
this as a best-practice in the repository as adding `override` to such
implemented members will cause TS to complain if an abstract member is
removed, but still implemented by derived classes.
More details: https://github.com/microsoft/TypeScript/issues/44457.
PR Close#42512
We accidentally started shipping `.mjs` files for the following
modules (or module paths) as of the v12.1.0-next.2 tag:
- `@angular/compiler-cli`
- `@angular/common/locales`
- `@angular/bazel`
- `@angular/benchpress`
- `@angular/core/schematics`
- `@angular/elements/schematics`
- `@angular/language-service`
- `@angular/localize/schematics`,
- `@angular/localize/tools`
- `zone.js`
This did not cause any issues for consumers but we
want to not ship these files without having them wired
up in `package.json` files. We accidentally started shipping
these `.mjs` files due to a NodeJS update which wired up the
other JavaScript module output flavors in the `pkg_npm` rule.
911529fd36
PR Close#42809
Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary
so that the Angular components repo can update, and it's generally
good to stay as up-to-date as possible with the Bazel rules as it's
easy to fall behind, and updating early allows us to discover issues
affecting our tooling earlier (where they are easier to address due to
e.g. potential breaking change policy).
PR Close#42760
Updates to TypeScript 4.3.4 which contains a fix for a printer
regression that caused unexpected JavaScript output with our
compiler transforms.
See: https://github.com/microsoft/TypeScript/pull/44070.
Updates to TypeScript 4.3.4 which contains a fix for a printer
PR Close#42600
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
