With this change we automate the generation of `@angular/cli/lib/config/schema.json`. While on paper we could use quicktype for this. Quicktype doesn't handle `patternProperties` and `oneOf` that well.
How does this works?
Relative `$ref` will be resolved and inlined as part of the root schema definitions.
Example
```json
"@schematics/angular:enum": {
"$ref": "../../../../schematics/angular/enum/schema.json"
},
```
Will be parsed and transformed to
```json
"@schematics/angular:enum": {
"$ref": "#/definitions/SchematicsAngularEnumSchema"
},
"definitions: {
"SchematicsAngularEnumSchema": {
"title": "Angular Enum Options Schema",
"type": "object",
"description": "Generates a new, generic enum definition for the given or default project.",
"properties": {...}
}
}
```
This uses `git merge-base --fork-point master` which currently is not yielding a SHA on the patch branch. In some cases merge-base will not working as expected when base is ahead. See https://public-inbox.org/git/xmqq375okvxy.fsf@gitster.mtv.corp.google.com/T/#r3830f032d76f39b82d0ffe7f8bd77351cf634d29
This validation checks if `DO_NOT_SUBMIT` string literal has been added using `git diff`, when present validation will fail.
This check is unneeded as we do not use the `DO_NOT_SUBMIT` pattern, as we typically use `wip!` commit message types.
`--tag` now must be explicitly specified rather than defaulting to `latest`. It is also validated to be one of the expected set of tags. There is a new `--tagCheck false` flag that will skip this in order to handle one-off custom tags if necessary in the future.
Apparently NPM requires that all releases have tags (defaulting to `latest` if not explicitly specified), so there is no way to choose **not** to push a new tag. That means that you can't push `10.0.x` and then push `9.0.x` without either using `v9-lts` or clobbering `latest`. The `--tag` requirement should hopefully enforce this restriction to avoid a potential release footgun.
Flag arguments provided by minimist are always strings. Both `--branchCheck` and `--versionCheck` failed to take this into account and were incorrectly typed as a result. Now boolean flags are parsed into actual boolean types which can be used more intuitively.
This includes a new `--registry` flag to the `dist-tag` command and defaults it to Wombat. This way NPM commands will explicitly use the correct registry.
We can't guarantee that the user provided these options at compile time, so all options should include `undefined` in their types. This makes the type system a little smarter and hopefully prevent future mistakes. Fortunately we were already doing the right thing, this will make sure we continue to do so in the future.
I opted to use `Partial<DistTagArgs>` so that all future flags would be implicitly forced to be optional. Otherwise, we may forget to make them optional and potentially introduce a bug.
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.
