This commit updates the payload sizes for angular.io to make it easier
to identify payload size changes from an imminent update of `@angular/*`
packages.
PR Close#42776
make sure that the top-menu links don't get overlapped by
the search input, regardless on the browser's font-size and
the window's width
make also sure that the header's logo does not overlap the search
input on narrow windows, again regardless on the browser's font-size
PR Close#42753
Currently if a top-level target or file within `//dev-infra` is
being referenced. like `//dev-infra:tsconfig`, then the label
is not subsituted properly and breaks consumption of the built
NPM package.
PR Close#42754
DTS bundling, will cause originally namespaced imports become namespace declarations within the same file. Example:
Before bundling
```ts
import * as i1 from './router';
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
After bundling
```
declare namespace i1 {
export {
RouterOutletContract,
RouterOutlet
}
}
export declare class RouterModule {
constructor(guard: any, router: Router);
static ɵmod: i0.ɵɵNgModuleDeclaration<RouterModule, [typeof i1.RouterOutlet...]>;
}
```
And therefore this commit adds support for reflecting types that are defined in such namespace declarations.
Closes#42064
PR Close#42728
Given we have updated API extractor to the most recent
version, we need to update the API goldens because the
latest version uses alias exports to avoid collisions with
default library globals (like `Event`).
PR Close#42737
Updates the api-extractor dependencies of the repository, and within
the `@angular/bazel` package so that TypeScript 4.3 is supported when
a flattened typings file is generated. Without this update, the api
extractor could fail if a referenced tsconfig use a TS 4.3-only option such as
`noImplicitOverride`.
Note: This could also be considered a `feat:` for `@angular/bazel`,
but this package is not part of the public API anyway and we'd want
that change to land in the patch branches too (to keep the goldens
in sync between release branches as much as possible)
PR Close#42737
Tools that are shipped as a Bazel rule with the shared dev-infra
tool require a specific `tsconfig` as otherwise `ts_library` will
accidentally look for a tsconfig in `@npm//:tsconfig` and the build
will fail. We bring in our dev-infra tsconfig and reference it
explicitly.
PR Close#42737
Since the recent update in the changelog format, the commit SHAs and PR
numbers referenced there were not links, making it less straight-forward
to get to the commit/PR corresponding to a change. The changelog
generation tooling has been updated in a previous commit to output links
for future changelog entries.
This commit updates existing entries in `CHANGELOG.md` to have links for
commit SHAs and corresponding PR numbers.
PR Close#42732
Previously, the commit SHAs and PR numbers referenced in the generated
`CHANGELOG.md` were not automatically converted to links in the GitHub
UI (as happens for release notes and issue/PR comments). This made it
less straight-forward for someone reading the changelog to get to the
commit/PR corresponding to a change.
This commit updates the tooling that generates the changelog to convert
the commit SHA and the corresponding PR number (referenced at the end of
the commit message header) to links.
PR Close#42732
Previously, the condition for showing the top-menu nav-menu in the
sidenav was the same as that for switching the sidenav mode from docked
(`mode: side`) to floating (`mode: over`). Therefore, the `isWide` input
of the corresponding `NavMenuComponent` could be hard-coded to `false`
(since the component would only be shown when the sidenav was in
floating mode).
In 61f6ed2fdfe58679cfada861624c759f1572a430, these two desicions were
decoupled, which would result in the top-menu nav-item being shown in
the sidenav while the sidenav is in docked mode (and thus the `isWide`
input should be set to `true`).
This commit fixes it by setting the `isWide` input based on the value of
the `dockSideNav` property, as happens for the rest of the nav-menus.
PR Close#42747
Previously, the `AppComponent#showTopMenu` property was taken into
account when determining the `MatSidenav#mode` value. However, this was
redundant, because in the only case in which the use of `showTopMenu`
would make a difference (i.e. when `dockSideNav` was true and
`isSideNavDoc` was false) the sidenav would be closed and the hamburger
menu button would not be visible (thus there would be no way to open it
manually).
This commit simplifies the condition for determining the sidenav mode by
removing `showTopMenu` from the expression.
PR Close#42747
Historically, our Language Service was built with the potential to be a
drop-in replacement for the TypeScript Language Service with the added
benefit of being able to provide Angular-specific information as well.
While our VSCode extension does not use the Language Service in this
way, it appears that other community-contributed plugins do. We don't
really officially support this use-case but there's not real reason for
us to override the TypeScript Language Service's
implementation in the VE Angular Language Service so that it returns
`undefined`. As with other non-implemented methods, we can just allow
this to be deferred to TSLS.
fixes#42715
PR Close#42727
When the template type checker try to get a symbol of a template node, it will
not return the directives intended for an element on a microsyntax template,
for example, `<div *ngFor="let user of users;" dir>`, the `dir` will be skipped,
but it's needed in language service.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1420
PR Close#42640
When `TestBed.compileComponents` is called under ViewEngine, we kick off a compilation and return a promise that resolves once the compilation is done. In most cases the consumer doesn't _have_ to await the returned promise, unless their components have external resources.
The problem is that the test could be over by the time the promise has resolved, in which case we still cache the factory of the test module. This becomes a problem if another compilation is triggered right afterwards, because it'll see that we still have a `_moduleFactory` and it won't recreate the factory.
These changes resolve the issue by saving a reference to the module type that is being compiled and checking against it when the promise resolves.
Note that while this problem was discovered while trying to roll out the new test module teardown behavior in the Components repo (https://github.com/angular/components/pull/23070), it has been there for a long time. The new test behavior made it more apparent.
PR Close#42669
For the last years the Angular repositories relied on `ts-api-guardian`
for testing the public API signature. This project worked well in
general but its another inconvenience to maintain if we could rely on
Microsoft's `api-extractor` tool.
Especially since with TypeScript 4.3 issues with export aliases appeared
that would require us to extend TS API guardian to support such exports.
This is not as straightforward as it sounds, given it requires rewriting
of declarations to show-case the proper name in the API golden. Microsoft's
API extractor has integrated support for this.
As of TypeScript 4.3, we want to start using the new `override` keyword.
We are not able to use that keyword currently because an old version of
API extractor is used in the `ng_module` rule to flatten the types into
a single file. To fix this, we need to update `api-extractor`, but this
unveils the issue with TS API guardian because the most recent version
of api-extractor uses alias exports to avoid potential conflicts
with globals available through the TypeScript default libraries (e.g.
`dom.d.ts`).
PR Close#42688
As of ES2021, JavaScript allows using underscores as separators inside numbers, in order to make them more readable (e.g. `1_000_000` vs `1000000`). TypeScript has had support for separators for a while so these changes expand the template parser to handle them as well.
PR Close#42672
Previously, if there were two tags with the same "name" or "property" attribute selector,
then only the first was checked for duplicates when deciding whether to add a new meta
tag.
Fixes#42700Fixes#19606
PR Close#42703