This is necessary as `rules_js` requires this "common name" when dealing
with Yarn workspaces, linking first party dependencies automatically.
In the future, we may be able to send a PR to `rules_js` to support a
custom name somehow.
* Removes `interop_deps` from the `ts_project` interop macro.
* Keeps `_rjs` suffix for now as we still need the interop targets for
e.g. `jasmine_node_test` and the `rules_nodejs` linker.
In follow-ups we can remove the suffix, and interop layer.
To avoid the need to perform Node.js resolution for the typical case of a relative
builder schema, a check is now performed to determine if a schema path within the
build manifest appears to be relative.
Due to bazel rules_nodejs caching, several additional `JSON.parse` usages were not
caught in the first set of fixes. These have now been addressed. Also,
the `must-use-promises` rule has been patched to match the behavior of the
`@typescript-eslint/no-floating-promises` for consistency.
The bazel option `suppressTsconfigOverrideWarnings` was also removed from the
`tsconfig` as it is a no-op and was previously used for now removed feature.
Test files are currently excluded from the `JSON.parse` rule to avoid large
changes to test code.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
When resolving a builder alias, the base path for the resolution will now
use the containing package. This prevents potential resolution failure due
to varying package manager installation strategies.
A builder's manifest definition within a package (typically `builders.json`) can now contain
a string value that will be used as a builder specifier when loading the named builder. This
allows a builder name to be aliased to another builder. The other builder may also be in
another package.
The build resolution logic has also been updated to remove use of the global `require` to
support eventual direct ESM usage.
The dynamically compiled ESM import helper is now cached to prevent the need
to recompile the helper function everytime a load ESM helper call is made.
This helper is currently used to workaround dynamic import limitations with
the TypeScript compilation output. Once the build process is updated, it will
no longer be required.
G3 is now using RXJS version 7 which makes it possible for the CLI to also be updated to RXJS 7.
NB: this change does not remove all usages of the deprecated APIs.
Closes#24371
When performing a release via the dev-infra `ng-dev` tooling, the release
builds for the packages that will be published are now performed using bazel.
Prior to this, the release builds were performed using a custom build script
that programmatically invoked TypeScript APIs. The Bazel build and discovery
process for the releasable packages is performed by a script that is based on
the scripts from components and framework repositories. Several small modifications
were performed to match the behavior and structure of the cli repository:
* Use of `packages` as the source root in the bazel query
* Use of `pkg_npm` rule in the bazel query
* Partial transition to native Node.js `fs` APIs instead of `shelljs`
* Directory creation per package when copying output (supports multiple package scopes)
* Copying of archives (tgz) for each package
The snapshot and local build capabilities are not modified as part of this change
but will be merged in a followup as part of a larger transition to use bazel
throughout the package build process.
Prepares the `@angular-devkit/architect` package for the eventual change of enabling the
TypeScript `useUnknownInCatchVariables` option. This option provides additional
code safety by ensuring that the catch clause variable is the proper type before
attempting to access its properties. Similar changes will be needed in the other
packages in the repository prior to enabling `useUnknownInCatchVariables`.
The `esModuleInterop` option is recommended to be enable by TypeScript and corrects several assumptions TypeScript would otherwise make when importing CommonJS files.
This option change helps ensure compatibility as packages move towards ESM.
Reference: https://www.typescriptlang.org/tsconfig#esModuleInterop
With this change, the architect can be configured to use a default configuration when it's not provided as part of the target.
Consider the below, where `defaultConfiguration` is configured to `production`. Running `ng build` will be invoked with "production" configuration.
```js
"build": {
"builder": "@angular-devkit/build-angular:browser",
"defaultConfiguration": "production",
"options": {
...
},
"configurations": {
"production": {
...
}
}
}
```
This change allows architect runtime implementations to have more control over how builder information and options for targets are found. A workspace file (and accompanying definition class) is not necessarily needed now. This also has benefits for unit testing by reducing the amount of potential setup needed per test.
This commit makes a few minor changes to enable syncing the CLI repository
into google3.
1. mark pkg_tar and pkg_npm as external
2. remove dependencies (marked as comment) which are stale in google3
3. remove TS files generated from JSON schema in BUILD files since these
files are compiled and added to the g3 codebase at sync time
4. Some minor typing changes
5. Remove duplicate licenses
6. mark dependencies which are not available in g3 as external
7. Immediately type the result of JSON.parse() as required by g3 linter.
Otherwise, the type defaults to `any`.
Contains fixes related to the symlink behaviour inside of bazel. Without it, webpack needs to be configured to be aware of symlinks and preserve the paths.
Without this change, module names will be computed with incorrect paths containing duplicate path fragments (e.g. `@angular-devkit/architect/testing/testing/test-logger`).
Add support for parsing multiple configurations in a single string using comma as a separator.
This support is only at the host level (`WorkspaceNodeModulesArchitectHost` in this case) and does not change the underlying Architect API.
Different hosts are able to compose target options in different ways.
* refactor(@angular-devkit/architect): use standard node resolution methods where possible
* refactor(@angular-devkit/core): use standard node resolution methods where possible
