This change updates the build configuration to include the
@angular/language-server package in the standard framework release
output.
By integrating it into the release train, we ensure that it is versioned and published consistently with the rest of the Angular framework.
PR Close#64306
Update the bazel query for finding all releasable packages to look for all targets with the name
`npm_package` that contain the expected tag.
PR Close#61879
The bazel npm package is no longer needed and currently breaks
as we started using a 1P pnpm linked package that would otherwise
end up being pulled into this legacy rule.
PR Close#61826
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
We are no longer publishing Angular Bazel to npm, but we are still
using it in the components repo. We should still publish it to
benefit from e.g. the APF v16 changes.
PR Close#49583
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
We need to switch the package builder to ESM or TS, like we did
in the components repo, but for now until we can, the release script
should work by loading the package builder CJS through the dynamic
import expression.
PR Close#46454
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
The package builder script should respect the `BAZEL` environment
variable for running Bazel. If not set, it can fallback to bazelisk
from the `node_modules`. Respecting this variable allows for users
with a global `bazel` binary. This is desirable in some situations,
like on Windows, where running Bazel inside of the Yarn environment
seems slower than running a global variant. This could appear like that
because projects might use different Bazel versions. In some cases,
developers would want to use a single (already-warmed-up) instance of
Bazel instead of launching different versions using bazelisk.
(e.g. when switching a lot between repos like COMP, FW or CLI..)
In any case, it doesn't hurt providing this flexibility for advanced
use-cases. It's low-effort to maintain and is respected in COMP as well.
PR Close#43431
Sets the executable bit for the build-packages-dist script so that
the script can be invoked directly without having to explicitly
prefix it with the `node` command.
PR Close#43431
Currently the ng-dev release tool always run `bazel clean` before
calling the configured build release function. The clean is necessary
to ensure the release output is actually built; and not restored
from previous builds which could have different bazel workspace
status variables (which provide the NPM package version).
Instead of doing this as part of the release tool, the
actual script running to build the release output should
run the `bazel clean`. The release tool does not intend to
know about details on how the release output is built. This
is necessary because the build setup could vary between version
branches (especially for older ones; such as LTS version branches).
PR Close#42101
Previously, the `angular-in-memory-web-api` package was built in
`dist/packages-dist/misc/angular-in-memory-web-api/`. This was different
from other Angular packages, which were placed directly in
`dist/packages-dist/`. This caused the `create-package-archives.sh`
script to create an invalid `misc.tgz` archive (i.e. treating the
`misc/` subdirectory as a package).
See, for example, the artifacts [here][1].
This commit changes the build scripts to have the
`angular-in-memory-web-api` package built in
`dist/angular-in-memory-web-api-dist/`, similar to how the `zone.js`
package is handled. It also updates the CircleCI config to correctly
publish the `angular-in-memory-web-api` package to CI build artifacts.
[1]: https://circleci.com/gh/angular/angular/951491
PR Close#41429
This commit updates the `build-ivy-npm-packages.js` script to also build
the `angular-in-memory-web-api` package. This could be used if someone
wanted to test the Ivy packages in docs examples or an integration test.
PR Close#41429
This commit makes the build scripts for the various packages (framework,
`@angular/dev-infra-private`, `angular-in-memory-web-api`, `zone.js`)
consistent. This makes it easier to maintain them (e.g. make similar
changes across all build scripts).
PR Close#41429
In some cases, we want to test the AIO app or docs examples against the locally built `angular-in-memory-web-api` for example to ensure that the changes in a commit do not introduce a breaking changes.
PR Close#41313
Previously, we could not use `npm_package.pack` for building the Zone.js
package due to a bug in Windows. This bug has been fixed in version
2.3.0 of `bazelbuild/rules_nodejs`.
Now that we have updated `bazelbuild/rules_nodejs` to version 2.3.3
(in #40581) we can replace `npm pack` with `npm_package.pack`.
PR Close#40592
In older versions of `bazelbuild/rules_nodejs`, the `npm_package.pack`
rule does not work on Windows. This has been fixed in
bazelbuild/rules_nodejs#2257, but the fix is not available before
[version 2.3.0][1].
Currently, we use version 2.2.0 (see [WORKSPACE][2]). In order to allow
the `zone-js-builder.js` script to work on Windows, this commit switches
to using `npm pack` directly, intead of relying on `npm_package.pack`.
For reference, the version of `bazelbuild/rules_nodejs` was updated to
2.3.2 in PR #39636, but this was later reverted due to CI flakes
(4e6d69cc85).
[1]: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.3.0
[2]: fc64fa8e1a/WORKSPACE (L12)
PR Close#40557
The scripts that build the Angular and Zone.js NPM packages rely on
absolute paths in order to work correctly regardless of what the current
working directory is when the scripts are invoked. However, the
`npm pack` command executed in the `zone-js-builder.js` script outputs
the generated `.tgz` archive in the current working directory. This
causes the script to fail when invoked for any working directory other
than the project root directory.
This commit fixes this by ensuring the `npm pack` command is run with
the project root directory as the working directory. This allows the
build scripts to run correctly regardless of the working directory they
are invoked from.
PR Close#39455
Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target
bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may
generate different results, for example, Zone.js 0.11.0's issue is `package.json`
define files array which make the bundle only include the files in the files array.
So this PR install the zone.js package from the archive generated from `npm_package.pack` rule.
PR Close#38649
Historically files to be formatted were added to a listing (via matchers)
to be included in formatting. Instead, this change begins efforts to
instead include all files in format enforcement, relying instead on an
opt out methodology.
PR Close#36940
In some cases, we want to test the AIO app or docs examples against the
locally built Angular packages (for example to ensure that the changes
in a commit do not introduce a breaking change). In order to achieve
this, we have the `ng-packages-installer` script that handles updating
a project's `package.json` file to use the locally built Angular
packages (and appropriate versions for their (dev-/peer-)dependencies).
Previously, `ng-packages-installer` would only consider the locally
built Angular packages (from `dist/packages-dist/`). However, given that
Zone.js is now part of the `angular/angular` repo, it makes sense to
also use the locally built Zone.js package (from `dist/zone.js-dist/`).
Otherwise, the tests might fail for commits that update both the Angular
packages (and related docs examples) and the Zone.js package. An example
of such a simultaneous change (that would have broken tests) is #33838.
This commit updates the script to install the locally built Zone.js
package (in addition to the Angular ones). The commit ensures that the
Zone.js package will always be available alongside the Angular packages
(i.e. that the Zone.js package will be built by the same script that
builds the Angular packages and that the `dist/zone.js-dist/` directory
will be cached on CI).
Note: This problem was discovered while enabling docs examples unit
tests in #34374.
PR Close#35858
Creates the scaffolding for an @angular/dev-infra-private package
which will not be published to npm but will be pushed to
https://github.com/angular/dev-infra-private-builds repo for each
commit to master.
The contents of this npm package will then be depended on via
package.json dependency for angular/angular angular/angular-cli and
angular/components.
PR Close#35862
This reverts commit 7d832ae1001b6264bb7124086089e9e69c10c9b6; breaks CI
with error `Concurrent upstream jobs persisted the same file(s) into the workspace:`
PR Close#35857
In some cases, we want to test the AIO app or docs examples against the
locally built Angular packages (for example to ensure that the changes
in a commit do not introduce a breaking change). In order to achieve
this, we have the `ng-packages-installer` script that handles updating
a project's `package.json` file to use the locally built Angular
packages (and appropriate versions for their (dev-/peer-)dependencies).
Previously, `ng-packages-installer` would only consider the locally
built Angular packages (from `dist/packages-dist/`). However, given that
Zone.js is now part of the `angular/angular` repo, it makes sense to
also use the locally built Zone.js package (from `dist/zone.js-dist/`).
Otherwise, the tests might fail for commits that update both the Angular
packages (and related docs examples) and the Zone.js package. An example
of such a simultaneous change (that would have broken tests) is #33838.
This commit updates the script to install the locally built Zone.js
package (in addition to the Angular ones). The commit ensures that the
Zone.js package will always be available alongside the Angular packages
(i.e. that the Zone.js package will be built by the same script that
builds the Angular packages and that the `dist/zone.js-dist/` directory
will be cached on CI).
Note: This problem was discovered while enabling docs examples unit
tests in #34374.
PR Close#35780
This commit moves the build-related scripts
(`build-ivy-npm-packages.js`, `build-packages-dist.js` and
`package-builder.js`) to a dedicated directory to keep the `scripts/`
directory cleaner.
It also moves the logic for building the `zone.js` package to a separate
script, `zone-js-builder.js`, to make it re-usable. A subsequent commit
will use it to build the `zone.js` package when building the Ivy Angular
packages as well.
PR Close#35780
* Remove now unnecessary portions of build.
* Add a compilePackageES5 method to build ES5 from sources
* Rework all package.json and rollup config files to new format
* Remove "extends" from tsconfig-build.json files and fixup compilation roots
PR Close#18541
Previous to 2.x there were some source maps distrubted, but they didn't go
all the way back to the TypeScript sources and they weren't available for
all JavaScript distrubted to NPM.
With this change source maps will be available for FESM distributions as
well as UMD and will go all the way back to TypeScript sources.
Fixes#15184
