We used to use `scripts/release.ts` to update the monorepo.json, which
used to contain the current versions of all packages within the CLI
repo. However, since 08e91a94ab4d35303e4e00efa888cfd788aecad7
we no longer keep track of versions in monorepo.json.
Currently, before each publish, a git tag is created and all packages
are versioned based off the latest tag.
Since we no longer use `release.ts` for publishing, this commit deletes
the file entirely.
The script could be used to print out the versions we are about to publish,
but this is already covered by `yarn admin packages --version`.
This is useful for the caretaker to confirm the version numbers prior to
publishing the packages.
The commit linter expects a certain type and/or scope in the commit message,
but if the right type/scope is not provided it doesn't tell us what to do.
Instead of this:
```
The following commit has an unknown type. You can use wip: to avoid this.
```
It now outputs this:
```
The following commit has an unknown type. It must be one of [docs, refactor, style, test, feat, fix, build, revert, ci, release]. You can use wip: to avoid this.
```
With this change we replace the custom rimraf implementation in the build script with the rimraf npm package. The main reason for this change is because `dist` can be a symlink when building with bazel but our implementation doesn't that.
If no --registry argument is provided when calling to publish
use the Wombat proxy. Additionally, updates the release process
documentation to instruct usage of the Wombat proxy.
If generating a changelog between tags that are on different branches (e.g., 9.0.3 on 9.0.x and 9.1.0-next.0 on master), commits that were cherry-picked and present in the previous version would also show in the newer version's changelog. This update analyzes the commits and excludes any that fit this scenario. Any commits that had conflicts will not be able to be matched authoritatively. Manual review of the generated changelog may still be needed for attempted cherry-pick commits that had conflicts.
This label should be placed by the author (or last reviewer if author is not a collaborator) when the PR is complete and ready to merged. This requires the author to explicitly acknolwedge that they are done with the PR and the caretaker is free to merge it. This label brings the CLI caretaking process into alignment with the frameworks and components repos.
I wrote down my understanding of the best ways to build/run/test/debug this repository.
A couple other random things included here:
* Removed an extraneous `debugger;` statement which I kept hitting.
* Removed the `watch` scripts which are no longer used and don't need to be supported.
* Removed `yarn test-cli-e2e`, as it alters the $PATH and can use the wrong `ng` instance.
* build: yarn upgrade lock update
* build: change sauce connect proxy name to avoid npm package shadowing
`sauce-connect` is an old npm package. Using the name for the saucelabs proxy tool causes false security vulnerability warnings.
* build: update license exceptions
mainly removal of now unneeded exceptions
* test: update ng-packagr builder tests to work on Windows
* build: add ng packagr test large for ivy
* test: fix web-worker test in ivy
Previously, we were not testing web workers under Ivy as we were overriding tsconfig.app.json entirely without including enableIvy.
When enabling Ivy we are getting warning of files that are part of the compilation which causing a warning to show and break the test.
* build: update ng-packagr to `^5.4.0`
* test: display ivy mode message once
Closes#13228
It is currently unused and requires an old version of the `source-map` package. This old version conflicts with the use of newer versions that are required to provide the necessary functionality and performance within the published packages.
