A few leftovers from from `@bazel/bazel` to `@bazel/bazelisk` migration
are still there. This commit fixes those, so that the repository no
longer relies on `@bazel/bazel`.
PR Close#36132
When using `platformBrowserDynamic().bootstrapModule()`, it is possible
to set `defaultEncapsulation` and `preserveWhitespaces` as default
configuration to influence how components are compiled. When compiling
components in JIT with Ivy, these options were not taken into account.
This commit publishes the options to be globally available, so that the
lazy compilation of JIT components has access to the configured
bootstrap options. Note that this approach does not allow changing the
options once they have been set, as Ivy's compilation model does not
allow for multiple compilations to exist at the same time.
For applications that bootstrap multiple modules, it is now required
to provide the exact same bootstrap options. An error is logged if
incompatible bootstrap options are provided, in which case the updated
options will be ignored.
Fixes#35230
Resolved FW-1838
PR Close#35534
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
When two entry-points overlap, ngcc may attempt to process some
files twice. Previously, when this occured ngcc would just exit with an
error preventing any other entry-points from being processed.
This commit changes ngcc so that if `errorOnFailedEntryPoint` is false, it will
simply log an error and continue to process entry-points. This is useful when
ngcc is processing the entire node_modules folder and there are some invalid
entry-points that the project doesn't actually use.
PR Close#36083
Previously, when an entry-point contained code that caused its compilation
to fail, ngcc would exit in the middle of processing, possibly leaving other
entry-points in a corrupt state.
This change adds a new `errorOnFailedEntryPoint` option to `mainNgcc` that
specifies whether ngcc should exit immediately or log an error and continue
processing other entry-points.
The default is `false` so that ngcc will not error but continue processing
as much as possible. This is useful in post-install hooks, and async CLI
integration, where we do not have as much control over which entry-points
should be processed.
The option is forced to true if the `targetEntryPointPath` is provided,
such as the sync integration with the CLI, since in that case it is targeting
an entry-point that will actually be used in the current project so we do want
ngcc to exit with an error at that point.
PR Close#36083
Later when we implement the ability to continue processing when tasks have
failed to compile, we will also need to avoid processing tasks that depend
upon the failed task.
This refactoring exposes this list of dependent tasks in a way that can be
used to skip processing of tasks that depend upon a failed task.
It also changes the blocking model of the parallel mode of operation so
that non-typings tasks are now blocked on their corresponding typings task.
Previously the non-typings tasks could be triggered to run in parallel to
the typings task, since they do not have a hard dependency on each other,
but this made it difficult to skip task correctly if the typings task failed,
since it was possible that a non-typings task was already in flight when
the typings task failed. The result of this is a small potential degradation
of performance in async parallel processing mode, in the rare cases that
there were not enough unblocked tasks to make use of all the available
workers.
PR Close#36083
Moving the definition of the `onTaskCompleted` callback into `mainNgcc()`
allows it to be configured based on options passed in there more easily.
This will be the case when we want to configure whether to log or throw
an error for tasks that failed to be processed successfully.
This commit also creates two new folders and moves the code around a bit
to make it easier to navigate the code§:
* `execution/tasks`: specific helpers such as task completion handlers
* `execution/tasks/queues`: the `TaskQueue` implementations and helpers
PR Close#36083
Similarly to what is done in `angular/components`, we should
cache the downloaded Bazel version (from `bazelisk`).
This reduces the overhead of downloading Bazel, and also avoids
the dependency on the external download server. We should avoid
external server dependencies as much as possible (see how the yarn
registry was flaky in the past).
PR Close#36098
The AOT compilation section of the `ngUpgrade` guide was
outdated/non-applicable. This commit hides the section to avoid confusion.
Fixing the section and re-introducing it is being tracked in #35989.
PR Close#36015
Previously, the `package.json` files added as boilerplate to docs
example projects of type `systemjs` were incorrect/outdated. They
contained unused dependencies and npm scripts and omitted used
dependencies.
This is not a big issue, because these examples are not offered as live
StackBlitz examples or downloadable ZIP archives, but having incorrect
`package.json` files is confusing and makes it more complicated to
update these examples.
This commit updates the `package.json` templates for the `systemjs` docs
examples and other configuration files to include used dependencies (and
remove unused ones). It also removes unused npm scripts.
PR Close#36015
Update dependencies.
Also, disable AOT tests for `systemjs`-type examples in Ivy mode,
because our current setup does not work with v9. See #35989 for details.
Fixes#34382Fixes#34383
PR Close#36015
Update `tsconfig[.*].json`.
Also, all make necessary changes to ensure the example apps can be
successfully built with the new, stricter type-checking options.
PR Close#36015
In the example apps used in the `ngUpgrade` guide, the AngularJS files
are loaded in `index.html` from `https://code.angularjs.org/`. Latest
browsers prevent loading the scripts from a page running on localhost
due to CORS:
```
Access to script at 'https://code.angularjs.org/1.5.5/angular.js' from origin
'http://localhost:9876' has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
header is present on the requested resource.
```
NOTE:
Loading the files from `code.angularjs.org` is not mentioned in the
guide, therefore it is not needed to mention this config change there.
PR Close#36015
The `build` and `run` properties in `example-config.json` are only used
in example projects of type `systemjs`. In CLI-type projects, `build`
and `run` are ignored.
PR Close#36015
The `unittesting` property in `example-config.json` is a remnant of the
setup (before `aio/` was moved into the `angular/angular` repo) and has
no effect any more.
PR Close#36015
The docs examples tests are run both with Ivy turned off and on. When
Ivy is turned on, ngcc is used to convert all dependencies (including
the Angular framework packages to Ivy).
Previously, in order to speed things up, the `test_docs_examples_ivy` CI
job would use Angular packages built with Ivy (from
`dist/packages-dist-ivy-aot`). This however was a deviation from what
happens in real-world applications.
This commit changes the `test_docs_examples_ivy` CI job to always use
the regular Angular packages (as published on npm) and use ngcc to
convert them to Ivy.
Relevant discussion:
https://github.com/angular/angular/pull/35091#discussion_r373775396
PR Close#36015
When ngcc is compiling an entry-point, it uses a `ReflectionHost` that
is specific to its format, e.g. ES2015, ES5, UMD or CommonJS. During the
compilation of that entry-point however, the reflector may be used to
reflect into external libraries using their declaration files.
Up until now this was achieved by letting all `ReflectionHost` classes
consider their parent class for reflector queries, thereby ending up in
the `TypeScriptReflectionHost` that is a common base class for all
reflector hosts. This approach has proven to be prone to bugs, as
failing to call into the base class would cause incompatibilities with
reading from declaration files.
The observation can be made that there's only two distinct kinds of
reflection host queries:
1. the reflector query is about code that is part of the entry-point
that is being compiled, or
2. the reflector query is for an external library that the entry-point
depends on, in which case the information is reflected
from the declaration files.
The `ReflectionHost` that was chosen for the entry-point should serve
only reflector queries for the first case, whereas a regular
`TypeScriptReflectionHost` should be used for the second case. This
avoids the problem where a format-specific `ReflectionHost` fails to
handle the second case correctly, as it isn't even considered for such
reflector queries.
This commit introduces a `ReflectionHost` that delegates to the
`TypeScriptReflectionHost` for AST nodes within declaration files,
otherwise delegating to the format-specific `ReflectionHost`.
Fixes#35078
Resolves FW-1859
PR Close#36089
The format property for ES5 bundles should be "module" or "es5"/"esm5",
but was "main" instead. The "main" property is appropriate for CommonJS
and UMD bundles, not for ES5 bundles.
PR Close#36089
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
Sets up a golden file for the TypeScript circular dependencies for
source files inside of the `packages/` folder.
Also sets up the appropriate Yarn shorthand scripts, and a codeowner
group that is soley responsible for verifying changes to the golden.
PR Close#35647
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
Wagner Maciel
ayazhafiz
danranVm
Andrew Kushnir
Paul Gschwendtner
JoostK
Pete Bacon Darwin
Judy Bogart
George Kalpakas
Greg Magolan