The shared dev-infra package from `HEAD` should not be installed
when running the `components-repo-unit-tests` job. This is done
because otherwise changes to the dev-infra package can result in
build setup issues for the CI job (while the goal of the CI job
is to test the framework)
PR Close#42268
This change moves the `dev-infra/browsers` folder into `dev-infra/bazel`.
The browser folder is providing custom configuration for Bazel, so it
should live within the `bazel` folder for a more well-structured
`dev-infra` folder.
PR Close#42268
Removes the duplicate `hasLocalChanges` method from the Git client. We
already have `hasUncommittedChanges`. Also removes a TODO for adding
`assertNoLocalChanges` as it seems more flexible to manually check
(i.e. better messaging with context on the current tool; e.g. "cannot
perform rebase")
PR Close#42409
Cleans up AIO's Sass files by:
* Switching them all over to the `@use`-based API from Angular Material.
* Removing the import of the Material theming API in a bunch of places that weren't using it.
* Migrating the new usages of Sass utility functions to the new syntax (e.g. `map.get` vs `map-get`).
* Fixing a few files that were using 4 spaces for indentation instead of 2.
PR Close#42442
As per SemVer, deprecations should only be released if the
minor version is incremented. This means that we should error
if commits w/ deprecations target an upcoming patch, LTS release.
Additionally, we also error if deprecations are made as part of
an upcoming release-candidate.
PR Close#42454
Adds the JSDoc `@throws` annotation to functions that would throw
within in the ng-dev tool. We want to add `@throws` so clearly
communicate if the invocation of a function results in errors or not.
This helps if IDEs show the `@throws` annotation on invocation, or
if TS ever lands a feature like Java `throws`, with more fine-grained
and typed error handling.
PR Close#42454
If a commit message currently mentions the breaking change or
deprecation note keywords, the commit message parse logic
accidentally picks up the note. This could then accidentally
prevent the commit from being merged (e.g. if the commit targets
the patch branch but mentioned the `BREAKING CHANGE: ` marker).
This commit switches the commit message notes pattern to only
capture notes at the beginning of a line (also allowing accidental
whitespace). This matches with the format we describe in our
contribution guide, as well as with our commit message validation
logic that also assumes notes at the beginning of a line.
PR Close#42436
Currently the commit message validation tool from `ng-dev` validates
the `BREAKING CHANGE:` commit message notes. This commit adds a similar
check for `DEPRECATED:` commit message notes.
Additionally, the check for breaking changes is reworked slightly to
be more tolerant (i.e. if there is only a single line break after the
summary; this is acceptable as per the parser and commonly done in the
COMP repo). The checks have been updated to capture wrong keywords that
are commonly used instead of the correct one. e.g. if a commit message
uses `DEPRECATIONS:` instead of `DEPRECATED:`, the validation will fail.
This prevents changelog generation issues where breaking change notes,
or deprecations are missing. This happened in the COMP repo where
the `DEPRECATED:` keyword was used incorrectly. See:
https://github.com/angular/components/commit/99391e79391d20c6ef2f95a3ea4fd6901dcb631d
PR Close#42436
We should primarily point readers to the stackblitz that contains the spec files and runs them.
The application stackblitz is secondary (and doesn't actually contain the spec files, which is confusing).
Fixes#38535
PR Close#42406
We recently updated `@octokit/rest` to a more recent version. For this
the Github client had to be refactored to account for new types of
Octokit. With the refactorings the authentication of the Github
client broke as we used an incorrect option for setting the OAuth
token. The TS transpilation did not fail because the Octokit types
support arbitrary options in the constructor. This is not solvable
on our side, so we cannot prevent similar issues in the future
unfortunately. Adding tests for authentication is not a reasonable
option either.
PR Close#42457
In the "Interceptor order" section of the HTTP guide there is a typo which incorrectly lists the same service twice when referring to two different services. The order that these services are listed is important, and this commit fixes the typo by listing the services in the correct order.
PR Close#42437
The compiler flag `compileNonExportedClasses` allows the Angular compiler to
process classes which are not exported at the top level of a source file.
This is often used to allow for AOT compilation of test classes inside
`it()` test blocks, for example.
Previously, the compiler would identify exported classes by looking for an
`export` modifier on the class declaration itself. This works for the
trivial case, but fails for indirectly exported classes:
```typescript
// Component is declared unexported.
@Component({...})
class FooCmp {...}
// Indirect export of FooCmp
export {FooCmp};
```
This is not an immediate problem for most application builds, since the
default value for `compileNonExportedClasses` is `true` and therefore such
classes get compiled regardless.
However, in the Angular Language Service now, `compileNonExportedClasses` is
forcibly overridden to `false`. That's because the tsconfig used by the IDE
and Language Service is often far broader than the application build's
configuration, and pulls in test files that can contain unexported classes
not designed with AOT compilation in mind.
Therefore, the Language Service has trouble working with such structures.
In this commit, the `ReflectionHost` gains a new API for detecting whether a
class is exported. The implementation of this method now not only considers
the `export` modifier, but also scans the `ts.SourceFile` for indirect
exports like the example above. This ensures the above case will be
processed directly in the Language Service.
This new operation is cached using an expando symbol on the `ts.SourceFile`,
ensuring good performance even when scanning large source files with lots of
exports (e.g. a FESM file under `ngcc`).
Fixes#42184.
PR Close#42207
The documentation suggested that `@types/*` scoped packages would
automatically be recognized, however the CLI configures a project such
that the package has to be explicitly added to the TypeScript
configuration files.
Closes#37572
PR Close#42417
We were linting against usages of `fdescribe` and `fit` by referencing the `no-jasmine-focus` rule which isn't installed, causing tslint to log the following:
```
Could not find implementations for the following rules specified in the configuration:
no-jasmine-focus
Try upgrading TSLint and/or ensuring that you have all necessary custom rules installed.
If TSLint was recently upgraded, you may have old rules configured which need to be cleaned
```
These changes switch to using the built-in `ban` rule.
PR Close#42415
This commit removes the `_typography-theme.scss` file that is currently
not used. The file contains a single Sass mixin
(`docs-site-typography-theme()`), which is never called.
PR Close#42396
This commit includes some minor refactorings and style changes as a
follow-up to PR #41129. (The changes were minor enough that didn't
warrant blocking the PR.)
PR Close#42396
This commit changes the `engines` rules in the root `package.json` as
well as the `package.json` used when working on docs example to also
accept Node.js versions greater than v14. This aligns them with
`aio/package.json` and allows using Node.js v15 and v16 (current) for
local development in the `angular/angular` repo.
Related to #42367.
PR Close#42387
Previously, the docs didn't say anything about the fact that the `novalidate` attribute is added to the enclosing form, or how to override that behavior. I have added a couple lines in the appropriate spot clarifying this issue.
PR Close#42377
Fixes#35373.
This changes the example from "run an arbitrary process" to "copy a file". This should make it a bit easier to follow, require less background knowledge to understand, and not use any platform-specific commands that won't work for Windows users.
The most glaring issue with this change is that this doc does not explictly specify how to build and run a builder. I've updated some of the files to hint at this a bit more (such as the `"implementation": "./dist/my-builder.js"`), but another pass is required to figure out the best way to compile a builder and how we want to structure this example to best communicate that.
PR Close#42371
This commit fixes some linting warning that were printed when running
`ng lint`. The warnings can be seen in the `lint` step of
[this CI job][1].
Most of the warnings were related to the deprecation of passing context
to Jasmine matchers in favor of using the [withContext()][2] matcher
(introduced in Jasmine v3.3.0).
[1]: https://circleci.com/gh/angular/angular/995543
[2]: https://jasmine.github.io/api/3.3/matchers.html#withContext
PR Close#42359
Previously the docs were very minimalistic. The most important thing missing from the docs
was that people should primarily use higher level APIs instead of using ROUTES directly.
It would be nice to holistically overhaul more of the router API docs, but that's out of
scope of this change.
Fixes#39350
PR Close#42398
mgechev
