Use an unstamped version of the compiler when it runs in `ng_project` as it will get stamped appropriately
whenever the generated code gets stamped after its usage."
PR Close#61479
* Fixes that the symbol extractor approval script was broken after some recent build changes.
* Fixes the `run_all_symbol_extractor_tests` script which wasn't resolving any targets, because the rule name changed.
PR Close#61407
Migrates `packages/core/schematics` to `ts_project`. As part of this,
this commit cleans up some of the mixed module types and tsconfigs in
the folder. A single tsconfig (and it's test variant) are now used.
For the shipped schematics, we explicitly use the `.cjs` extension, so
that the bundles are properly recognized as CommonJS; even if they are
part of the `type: module` `@angular/core` package.
The `package.json` with `type: commonjs` is removed from
`packages/core/schematics` as it's no longer needed given the explicit
extension & caused issues as schematics are compiled with ESM but are
only later bundled for shipping & some tests as ESM.
PR Close#61370
As we migrate more and more code to `ts_project`, we are ending up with
`.js` file extensions (ts_library did generate `.mjs` magically).
Since we don't want to get into the business of migrating
`nodejs_binary` targets at this point (in some cases we might)— we
should support pointing to such files.
PR Close#61370
As we roll out more PRs that migrate to `ts_project`, we need to make
sure that we don't break existing `tsec` targets. This PR copies the
original `tsec` Starlark code and adjusts it to work with the interop.
Note that we don't patch as this would unnecessarily complicate this
file that only exists during migration. Long-term, after migration, we
either need to consider switching to the new ESLint plugin that is being
worked on (I'm in contact with the team), or we send a CL to update the
Tsec Starlark code to keep our changes minimal and avoid scope increase.
PR Close#61275
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61312
Migrates `manual_api_docs` to `rules_js`. Since compiler CLI is ESM
compiled but doesn't have extensions, we can either bundle or simply use
the dependency as type only. This is easier and sufficient for this
use-case.
PR Close#61181
We don't need this tooling anymore because we are already validating
that there are no circular dependencies via the `ng-dev` tooling that
checks `.ts` files directly.
Also these tests never actually failed to my knowledge.
PR Close#61156
There is nothing in the Router that requires ZoneJS and we do not need
`fakeAsync` as a mock clock. We can instead use any mock clock implementation
to speed up test execution.
This removes ZoneJS completely from the bundle of the Router tests.
ZoneJS causes the stacks to be unreadable when combined with the massive
rxjs stack in the router transition.
PR Close#61078
The `ts_project` interop rule that we've built was also used in the
Angular CLI migration, and it allows us to mix `ts_project` and
`ts_library` targets; enabling an incremental migration. Additionally
set up the `ng_project` to replace `ng_module`.
PR Close#61087
This commit adds a step where we build all found targets in parallel, which speeds up the process of completing symbol extractor test/update.
PR Close#60573
Previously we never could use relative imports to import e.g. `Component`
in e.g. the `core/tests/bundling` folder. This was necessary because otherwise the
Angular compiler wouldn't process those files as it wouldn't recognize
the Angular decorator as the one from `@angular/core`.
Notably this still isn't a large issue because relative imports still
work for most core tests, that are JIT compiled!
For bundling tests though, or some smaller targets, our new upcoming
guidelines for using relative imports inside the full package; fall
apart. This commit unblocks this effort and allows us to use relative
imports in all tests of `packages/core`. This is achieved by leveraging
the existing `isCore` functionality of the compiler, and fixing a few
instances that were missing before.
PR Close#60268
Usage of the `fast-glob` package has been replaced with the `tinyglobby` package. The change reduces the number of transitive dependencies related to these packages from 17 to 2 while also maintaining equivalent functionality. This was also changed in the Angular CLI packages.
PR Close#60264
Switches the goldens for the symbol tests to be an array of strings, rather than an array of objects where each object only has a `name` property. This makes more compact, easier to read and easier to avoid merge conflicts.
PR Close#59147
When setting `"useDefineForClassFields": false`, static fields are compiled within a block that relies on the `this` context. This output makes it more difficult for bundlers to treeshake and eliminate unused code.
PR Close#58297
Replaces esbuild with Rollup for bundling schematics to support code splitting, as esbuild does not handle code splitting when targeting CommonJS modules.
**Before:**
```
du -sh dist/bin/packages/core/npm_package/schematics
7.7M dist/bin/packages/core/npm_package/schematics
```
**After:**
```
du -sh dist/bin/packages/core/npm_package/schematics
3.1M dist/bin/packages/core/npm_package/schematics
```
PR Close#57602
This commit reduces the bundle size of `@angular/core` by 19.5 MB by excluding sourcemaps from the schematics.
Since the `esbuild` rule doesn't allow disabling sourcemaps directly, we work around this by setting the sourcemaps to `external`. Afterward, we filter the output to include only the `.js` files.
PR Close#57545
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
