The Angular compiler creates two `ts.Program`s; one for emit and one for
template type-checking. The creation of the type-check program could
benefit from reusing the `ts.ModuleResolutionCache` that was primed
during the creation of the emit program. This requires that the compiler
host implements `resolveModuleNames`, as otherwise TypeScript will setup
a `ts.ModuleResolutionHost` of its own for both programs.
This commit ensures that `resolveModuleNames` is always implemented,
even if the originally provided compiler host does not. This is
beneficial for the `ngc` binary.
PR Close#39693
Previously, the indentation of code snippets in the "Cheat sheet" guide
was done using `<br>` elements (for line breaks) and ` ` HTML
entities (for space). This was laborious and put the onus on the author
to remember to use these symbols (instead of regular whitespace
characters).
(Discussed in
https://github.com/angular/angular/pull/41051#discussion_r585651621.)
This commit changes the way `<code>` elements are styles inside the
"Cheat sheet" guide to allow using regular whitespace characters in code
snippets. It also changes all `<br>`/` ` occurrences to `\n`/` `
respectively to make code snippets more readable in the source code.
PR Close#41051
The "Features" page organizes features in groups/rows of 3 features
each. On wide screens, all 3 paragraphs of a group/row can be shown next
to each other. On narrow screens (between 768px and 1057px), the layout
changes to stack the paragraphs vertically. On medium screens, however,
there is not enough space to show more than two paragraphs next to each
other.
Previously, the 3rd paragraph was wrapped over to the next line.
This commit improves the layout on medium screens by switching to
immediately stacking the paragraphs vertically as soon as there is not
enough space for them to be displayed in one row. Since the total width
is still too much for one paragraph, the paragraphs are limited to 80%
of the total width.
Before (on 1000px width): [features page (on 1000px) before][1]
After (on 1000px width): [features page (on 1000px) after][2]
[1]: https://user-images.githubusercontent.com/8604205/109825316-62128a00-7c42-11eb-8391-650201257274.png
[2]: https://user-images.githubusercontent.com/8604205/109825323-6343b700-7c42-11eb-86c1-e8307c5a727a.png
PR Close#41051
Previously, with the min width of 220px per item, several API list items
were truncated.
This commit increases the min width per item to 330px, which allows
almost all items to have their full text shown. It also increases the
API list page's max content width from 50em (800px) to 62.5em (1000px)
to allow items to be shown on three columns despite their increased
width. This increase in the content width shouldn't negatively affect
UX, since the API list page uses a multi-column layout (i.e. it does not
contain 1000px-lines of text.)
Before: ![api-list before][1]
After: ![api-list after][2]
[1]: https://user-images.githubusercontent.com/8604205/109396457-5f5e1f00-793a-11eb-80cf-1418f409325a.png
[2]: https://user-images.githubusercontent.com/8604205/109396659-499d2980-793b-11eb-95d3-f54250f7fab5.png
PR Close#41051
Previously, each marketing page used a different limit for its content's
width (if it had a limit at all) and implemented the width limiting in a
different way. Besides resulting in an inconsistent UX, this also made
it difficult to apply site-wide layout changes.
This commit makes the limit for most marketing pages consistent and uses
the same CSS class to make it easier to apply site-wide changes in the
future. The chosen limit is slightly larger than that of docs pages
(62.5em/1000px vs 50em/800px), because marketing pages have a different
type of content and layout (i.e. images, multi-column layout, etc.).
Finally, this commit also removes obsolete wrapper elements, CSS classes
and CSS styles, that are no longer necessary after the changes.
Notably, the homepage (`/`) and the "Contributors" page (`/about`) have
remained unchanged, because the former has its own layout that is
different from other marketing pages and the latter would offer a worse
UX with a small content width limit (as the one used on other marketing
pages).
The content widths of the rest of the marketing pages change slightly as
a result of the changes in this commit, but not in a way that would have
a negative impact on UX. More specifically:
| Page (URL) | Size before | Size after |
|:--------------|------------:|-----------:|
| `/contribute` | 880px | 1000px |
| `/events` | unlimited | 1000px |
| `/features` | 996px | 1000px |
| `/presskit` | 800px | 1000px |
| `/resources` | 800px | 1000px |
PR Close#41051
This commit removes an unnecessary wrapper `<div>` from the
"Cheat sheet" guide. The CSS styles that referenced the element's ID
(`#cheatsheet`) have been updated to use `.page-guide-cheatsheet`
instead.
PR Close#41051
Previously, styling of `<code>` elements utilized the `:not()` CSS
pseudo-class with multiple selectors (`:not(h1, h2, ...)`). It turns out
that older browsers (such as IE11) do not support multiple selectors in
a single `:not()` instance.
(See [MDN][1] and [CanIUse][2] for more info.)
This commit fixes `<code>` styling to use multiple separate `:not()`
instances instead (`:not(h1):not(h2)...`), so that they are styled
correctly on older browsers as well.
NOTE:
This change seems to trigger some kind of bug in LightHouse that causes
the a11y score of `/start` to be calculated as 0 (which is clearly
wrong). This happens on Linux (tested on CI and locally using the
Windows Subsystem for Linux (WSL)) - on Windows the score is computed
correctly as 98/100.
([Example failure][3])
The bug seems to be related to the layout of the content and goes away
if we change the viewport size (for example, switching to LightHouse's
`desktop` config) or make another change that affects the content's
layout (for example, reducing the padding of `<code>` elements).
To work around the issue, this commit updates the `test-aio-a11y.js`
script to test `/start-routing` instead of `/start`.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/:not#description:~:text=Using%20two%20selectors
[2]: https://caniuse.com/css-not-sel-list
[3]: https://circleci.com/gh/angular/angular/931038
PR Close#41051
The "Features" page organizes features in groups/rows of 3 features
each. On wide screens, all 3 paragraphs of a group/row can be shown next
to each other. On narrow screens, the layout changes to stack the
paragraphs vertically. On medium screens, however, the 3rd paragragh is
wrapped over to the next line.
Previously, the wrapped content was left-aligned, which left a lot of
empty space on the right.
This commit improves the layout on medium screens by ensuring the
paragraphs are horizontally centered (with space distributed evenly
around them).
Before: ![features page before][1]
After: ![features page after][2]
[1]: https://user-images.githubusercontent.com/8604205/109344670-b64ef000-7877-11eb-9013-890562ff2f3d.png
[2]: https://user-images.githubusercontent.com/8604205/109344678-b7801d00-7877-11eb-9224-d7715f7d7235.png
PR Close#41051
Previously, in contrast to docs pages, marketing pages had a non-fixed
top-menu, which meant that the top-menu would scroll out of the viewport
along with the rest of the content. This had a couple of downsides:
- The UI was different between pages (i.e. different top-menu behavior
on docs vs marketing pages).
- Since some of the marketing pages are long, it was not easy for people
to navigate to a different page (i.e. they had to scroll all the way
back up).
This commit improves the UX by using the same, fixed top-menu on all
pages, which restores consistency and allows the user to navigate around
more easily.
NOTE:
The old behavior (non-fixed top-menu) is kept on the homepage, since its
top-menu design in a little different than other pages (e.g. it uses a
transparent top-menu) and would not play well with a fixed top-menu.
PR Close#41051
Previously, injector definitions contained a `factory` property that
was used to create a new instance of the associated NgModule class.
Now this factory has been moved to its own `ɵfac` static property on the
NgModule class itself. This is inline with how directives, components and
pipes are created.
There is a small size increase to bundle sizes for each NgModule class,
because the `ɵfac` takes up a bit more space:
Before:
```js
let a = (() => {
class n {}
return n.\u0275mod = c.Cb({type: n}),
n.\u0275inj = c.Bb({factory: function(t) { return new (t || n) }, imports: [[e.a.forChild(s)], e.a]}),
n
})(),
```
After:
```js
let a = (() => {
class n {}
return n.\u0275fac = function(t) { return new (t || n) },
n.\u0275mod = c.Cb({type: n}),
n.\u0275inj = c.Bb({imports: [[r.a.forChild(s)], r.a]}),
n
})(),
```
In other words `n.\u0275fac = ` is longer than `factory: ` (by 5 characters)
and only because the tooling insists on encoding `ɵ` as `\u0275`.
This can be mitigated in a future PR by only generating the `ɵfac` property
if it is actually needed.
PR Close#41022
PR Close#41133
One of the main goals of the bundling tests is to verify that unused symbols are tree-shaken away in prod bundles.
Currently both Reactive and Template-driven test apps are merged into one. In order to make these tree-shaking
tests even more useful, this commit splits exiting test app into two, so that we can further optimize sets of
symbols that should be retained in both scenarios.
PR Close#41108
This commit adds a semi-comprehensive README file which describes the
design goals and implementation of the template type checking engine,
which powers the Angular Language Service as well as the main compiler's
understanding of types in templates.
PR Close#41004
The compiler performs cycle analysis for the used directives and pipes
of a component's template to avoid introducing a cyclic import into the
generated output. The used directives and pipes are represented by their
output expression which would typically be an `ExternalExpr`; those are
responsible for the generation of an `import` statement. Cycle analysis
needs to determine the `ts.SourceFile` that would end up being imported
by these `ExternalExpr`s, as the `ts.SourceFile` is then checked against
the program's `ImportGraph` to determine if the import is allowed, i.e.
does not introduce a cycle. To accomplish this, the `ExternalExpr` was
dissected and ran through module resolution to obtain the imported
`ts.SourceFile`.
This module resolution step is relatively expensive, as it typically
needs to hit the filesystem. Even in the presence of a module resolution
cache would these module resolution requests generally see cache misses,
as the generated import originates from a file for which the cache has
not previously seen the imported module specifier.
This commit removes the need for the module resolution by wrapping the
generated `Expression` in an `EmittedReference` struct. This allows the
reference emitter mechanism that is responsible for generating the
`Expression` to also communicate from which `ts.SourceFile` the
generated `Expression` would be imported, precluding the need for module
resolution down the road.
PR Close#40948
The import graph scans source files for its import and export statements
to extract the source files that it imports/exports. Such statements
contain a module specifier string and this module specifier used to be
resolved to the actual source file using an explicit module resolution
step. This is especially expensive in incremental rebuilds, as the
module resolution cache has not been primed during program creation
(assuming that the incremental program was able to reuse the module
resolution results from a prior compilation). This meant that all module
resolution requests would have to hit the filesystem, which is
relatively slow.
This commit is able to replace the module resolution with TypeScript's
bound symbol of the module specifier. This symbol corresponds with the
`ts.SourceFile` that is being imported/exported, which is exactly what
the import graph was interested in. As a result, no filesystem accesses
are done anymore.
PR Close#40948
Previously, when a payload size check failed, the error message prompted
the user to update the size limits using a CI-specific file path, which
was confusing (esp. for external contributors). See, for example,
https://circleci.com/gh/angular/angular/932733.
This commit improves the error message by printing the file path
relative to the repository root instead.
PR Close#41116
In Angular programs, changing a file may require other files to be
emitted as well due to implicit NgModule dependencies. For example, if
the selector of a directive is changed then all components that have
that directive in their compilation scope need to be recompiled, as the
change of selector may affect the directive matching results.
Until now, the compiler solved this problem using a single dependency
graph. The implicit NgModule dependencies were represented in this
graph, such that a changed file would correctly also cause other files
to be re-emitted. This approach is limited in a few ways:
1. The file dependency graph is used to determine whether it is safe to
reuse the analysis data of an Angular decorated class. This analysis
data is invariant to unrelated changes to the NgModule scope, but
because the single dependency graph also tracked the implicit
NgModule dependencies the compiler had to consider analysis data as
stale far more often than necessary.
2. It is typical for a change to e.g. a directive to not affect its
public API—its selector, inputs, outputs, or exportAs clause—in which
case there is no need to re-emit all declarations in scope, as their
compilation output wouldn't have changed.
This commit implements a mechanism by which the compiler is able to
determine the impact of a change by comparing it to the prior
compilation. To achieve this, a new graph is maintained that tracks all
public API information of all Angular decorated symbols. During an
incremental compilation this information is compared to the information
that was captured in the most recently succeeded compilation. This
determines the exact impact of the changes to the public API, which
is then used to determine which files need to be re-emitted.
Note that the file dependency graph remains, as it is still used to
track the dependencies of analysis data. This graph does no longer track
the implicit NgModule dependencies, which allows for better reuse of
analysis data.
These changes also fix a bug where template type-checking would fail to
incorporate changes made to a transitive base class of a
directive/component. This used to be a problem because transitive base
classes were not recorded as a transitive dependency in the file
dependency graph, such that prior type-check blocks would erroneously
be reused.
This commit also fixes an incorrectness where a change to a declaration
in NgModule `A` would not cause the declarations in NgModules that
import from NgModule `A` to be re-emitted. This was intentionally
incorrect as otherwise the performance of incremental rebuilds would
have been far worse. This is no longer a concern, as the compiler is now
able to only re-emit when actually necessary.
Fixes#34867Fixes#40635Closes#40728
PR Close#40947
In 6cff877 we broke the decorator docs because the
doc-gen no longer knew how to identify them.
This commit updates the dgeni processor responsible
for identifying the decorators in the code and ensures
that the docs are now generated correctly.
Fixes#40851
PR Close#41091
This commit adds `/tutorial` to the list of angular.io pages that we run
a11y tests against and updates the required scores to match the current
ones (to avoid a future regression going unnoticed).
PR Close#41103
This commit updates the `audit-web-app.js` script (used to run PWA and
a11y tests on angular.io) to also print the version of the browser used
to run the tests. This can help when debugging a CI failure.
PR Close#41103
setting the `hero` property as an optional property fixes the compilation
error: `Property 'hero' has no initializer and is not definitely assigned
in the constructor` when having the ts transpiler set to "strict" mode.
PR Close#40942
This commit adds a Forms-based test app into the `integration` folder to have an ability to measure and keep
track of payload size for the changes in Forms package.
PR Close#41045
We currently provide completions for DOM elements in the schema as well
as attributes when we are in the context of an external template.
However, these completions are already provided by other extensions for
HTML contexts (like Emmet). To avoid duplication of results, this commit
updates the language service to exclude DOM completions for external
templates. They are still provided for inline templates because those
are not handled by the HTML language extensions.
PR Close#41078
These constants were created in a very early phase of Ivy development.
They have never been used in the framework, no the build-optimizer tool.
PR Close#41040
Previously, `ɵɵgetFactoryOf()` was "privately" published from
`@angular/core` since in the past it was assumed that this
might be an instruction generated by the compiler.
This is not currently the case, so this commit removes it from
the private exports and renames it to indicate that it is a local
helper function.
PR Close#41040
This method does not appear to be used in the project.
This commit removes it and code that it exclusively
depended upon, or depended upon it.
PR Close#41040
Before `unknown` was available, the `never` type was used to discourage
application developers from using "private" properties. The `unknown` type
is much better suited for this.
PR Close#41040
This commit updates the Angular framework, Angular CDK/Material and
Angular CLI to latest stable versions (11.2.3, 11.2.2 and 11.2.2
respectively).
This update also fixes a Lighthouse audit fail due to
`@angular/core@11.0.0` being identified as vulnerable to XSS:
https://snyk.io/vuln/SNYK-JS-ANGULARCORE-1070902
Regarding the payload size increases, they are mostly attributed to
Angular Material:
- Before this commit: 448461 B
- After framework update: 448554 B ( +93 B)
- After Material update: 449292 B (+738 B)
- After CLI update: 449310 B ( +18 B)
PR Close#40994
PR Close#41069
In this version, we no longer need our custom logic to skip certain
HTTPS related audits on localhost, since Lighthouse will treat it as a
secure context (similar to how browsers do).
See also GoogleChrome/lighthouse#11766.
PR Close#40994
PR Close#41069
The compiler considers template diagnostics to "belong" to the source file
of the component using the template. This means that when diagnostics for
a source file are reported, it returns diagnostics of TS structures in the
actual source file, diagnostics for any inline templates, and diagnostics of
any external templates.
The Language Service uses a different model, and wants to show template
diagnostics in the actual .html file. Thus, it's not necessary (and in fact
incorrect) to include such diagnostics for the actual .ts file as well.
Doing this currently causes a bug where external diagnostics appear in the
TS file with "random" source spans.
This commit changes the Language Service to filter the set of diagnostics
returned by the compiler and only include those diagnostics with spans
actually within the .ts file itself.
Fixes#41032
PR Close#41070
The current logic in the compiler is to bail when there are errors when
parsing a template into an HTML AST or when there are errors in the i18n
metadata. As a result, a template with these types of parse errors
_will not have any information for the language service_. This is because we
never attempt to conver the HTML AST to a template AST in these
scenarios, so there are no template AST nodes for the language service
to look at for information. In addition, this also means that the errors
are never displayed in the template to the user because there are no
nodes to map the error to.
This commit adds an option to the template parser to temporarily ignore
the html parse and i18n meta errors and always perform the template AST
conversion. At the end, the i18n and HTML parse errors are appended to
the returned errors list. While this seems risky, it at least provides
us with more information than we had before (which was 0) and it's only
done in the context of the language service, when the compiler is
configured to use poisoned data (HTML parse and i18n meta errors can be
interpreted as a "poisoned" template).
fixes angular/vscode-ng-language-service#1140
PR Close#41068
An opening tag `<` without any characters after it is interperted as a
text node (just a "less than" character) rather than the start of an
element in the template AST. This commit adjusts the autocomplete engine
to provide element autocompletions when the nearest character to the
left of the cursor is `<`.
Part of the fix for angular/vscode-ng-language-service#1140
PR Close#41068
After my speaker meeting with the Geekle team, they communicated that
they moved the date to avoid colliding with ng-conf. Originally added
in#40697, per @mgechev.
PR Close#41050
The compiler's parsing code has logic to recover from incomplete open
tags (i.e. `<div`) but the recovery logic does not handle when the
incomplete tag is terminated by an EOF. This commit updates the logic to
allow for the EOF character to be interpreted as the end of the tag open
so that the parser can continue processing. It will then fail to find
the end tag and recover by marking the open tag as incomplete.
Part of https://github.com/angular/vscode-ng-language-service/issues/1140
PR Close#41054
This commit adds a new configuration option, `forceStrictTemplates` to the
language service plugin to allow users to force enable `strictTemplates`.
This is needed so that the Angular extension can be used inside Google without
changing the underlying compiler options in the `ng_module` build rule.
PR Close#41063
VSCode only de-duplicates references results for "go to references" requests
but does not de-duplicate them for "find all references" requests. The
result is that users see duplicate references for results in TypeScript
files - one from the built-in TS extension and one from us.
While this is an issue in VSCode (see https://github.com/microsoft/vscode/issues/117095)
this commit provides a quick workaround on our end until it can be addressed there.
This commit should be reverted when microsoft/vscode/issues/117095 is resolved.
fixes https://github.com/angular/vscode-ng-language-service/issues/1124
PR Close#41041
Previously, the event dates displayed on the angular.io "Events" page
(`/events`) was off by one day on timezones with a negative offset from
UTC. See
https://github.com/angular/angular/pull/41050#issuecomment-788958888.
This commit fixes it by using the `getUTC*` methods of the `Date` object
to extract the date info, which are not affected by the user's timezone.
PR Close#41053
At the moment, when passing an Angular Compiler option
in the `existingOptions` it doesn't override the defined in the TSConfig.
PR Close#40694
(cherry picked from commit b7c4d07e81)
PR Close#41036
Shifts colors to pass WebAIM contrast checker and adds media
query so that body padding is smaller at smaller widths.
Body padding responsiveness will help on StackBlitz and small
screens.
PR Close#40890
1. The error function throws, so no code after it is reachable.
2. Some switch statements are exhaustive, so no code after them are reachable.
PR Close#40984
Now the language service always uses the name of the JavaScript property on the
component or directive instance for this input or output. This PR will use the right
binding property name.
PR Close#41005
Ngcc uses the `paths` property to compute the potential base-paths
for packages that are being processed. If the `paths` contain a wildcard
`*` within a path segment, ngcc was not finding the base-path correctly.
Now when a wildcard is found, there is an additional search to look for
paths that might match the wildcard.
Fixes#41014
PR Close#41033
We need to explicitly set the `enableIvy` option in a tsconfig file
to tell StackBlitz not to use ViewEngine.
This commit will generate an appropriate tsconfig.json file in the
example data that is sent to StackBlitz, which matches the Ivy
setting of the AIO project itself.
PR Close#40930
This commit cleans up the styles and the elements/classes used for
styling the content of the `<aio-resource-list>` component.
This change has been extracted from #36045.
Co-authored-by: Stefanie Fluin <sjtrimble@gmail.com>
PR Close#40944
This commit replaces some outdated URLs in "Contribute" links (on the
"Contribute" page):
- `github.com/angular/material2` --> `github.com/angular/components`
- `github.com/angular/angularfire2` --> `github.com/angular/angularfire`
It also replaces the deprecated `md-button` attribute with `mat-button`.
PR Close#40944
Since `.filter-button` elements only appear inside `.group-buttons`
elements, this commit moves `.filter-button` CSS styles inside
`.group-buttons` styles.
PR Close#40944
Previously all github releases created by the release tooling tagged
releases as `latest`. Instead releases which are created for the `next`
tag on NPM should be tagged as `prerelease` for github.
PR Close#40999
Clearing the cached bazel outputs before building the artifacts for
publishing prevents an intermittent error found when the version is
cached between publishes.
PR Close#41000
The "Press kit" page has a "Terminology" section that lists a couple of
terms (currently AOT and JIT compilation).
This commit adds links to the corresponding entries in "Glossary" to
make it easier for people to find out what the terms mean.
PR Close#40945
Previously, when `ngcc` encountered an entry-point with a format-path
that pointed to a non-existing or empty file it would throw an error and
stop processing the remaining tasks.
In the past, we used to ignore such format-paths and continue processing
the rest of the tasks ([see code][1]). This was changed to a hard
failure in 2954d1b5ca. Looking at the code
history, the reason for changing the behavior was an (incorrect)
assumption that the condition could not fail. This assumption failed to
take into account the case where a 3rd-party library has an invalid
format-path in its `package.json`. This is an issue with the library,
but it should not prevent `ngcc` from processing other
packages/entry-points/formats.
This commit fixes this by reporting the task as failed but not throwing
an error, thus allowing `ngcc` to continue processing other tasks.
[1]: https://github.com/angular/angular/blob/3077c9a1f89c5bd75fb96c16e/packages/compiler-cli/ngcc/src/main.ts#L124Fixes#40965
PR Close#40985
These tests were relying upon unix-like paths, which
caused them to fail on Windows.
Note that the `filegroup` Bazel rule tends not to work well
on Windows, so this has been replaced with `copy_to_bin`
instead.
PR Close#40952
Some tools (such as Language Server and ng-packagr) only care about
the processed typings generated by ngcc. Forcing these tools to process
the JavaScript files as well has two disadvantages:
First, unnecessary work is being done, which is time consuming.
But more importantly, it is not always possible to know how the final bundling
tools will want the processed JavaScript to be configured. For example,
the CLI would prefer the `--create-ivy-entry-points` option but this would
break non-CLI build tooling.
This commit adds a new option (`--typings-only` on the command line, and
`typingsOnly` via programmatic API) that instructs ngcc to only render changes
to the typings files for the entry-points that it finds, and not to write any
JavaScript files.
In order to process the typings, a JavaScript format will need to be analysed, but
it will not be rendered to disk. When using this option, it is best to offer ngcc a
wide range of possible JavaScript formats to choose from, and it will use the
first format that it finds. Ideally you would configure it to try the `ES2015` FESM
format first, since this will be the most performant.
Fixes#40969
PR Close#40976
This commit updates compiler_spec.ts in the Ivy LS suite to utilize the new
testing environment which was introduced in the previous commit. Eventually
all specs should be converted, but converting one right now helps ensure
that the new testing env is working properly and able to support real tests.
PR Close#40966
Fixes error: `TS2564: Property 'heroes' has no initializer and is not definitely assigned in the constructor`
and makes `hero` property consistent with ch 3 (ref: #40942)
PR Close#40970
This is patch PR for #40954
Type guard should be colocated with the `NgLanguageService` interface,
not in `@angular/vscode-ng-language-service`.
PR Close#40954
PR Close#40968
Increases contrast of example copy.
Explicitly references inputs from labels.
Updates screenshot of styles that aren't accessible.
Removes the term master.
Provides more detailed alternate text for the image.
Adds padding to input so it is an easier target for touch or pointer.
PR Close#40575
The Angular LS does not provide quick info when the given position is not
inside a template. As an optimization, we can quickly look at the
file and determine if we are at a position that is part of an Angular
template. If not, we bail before asking the compiler for any more
information. Note that the Angular LS _already_ provides no quick info
when outside a template file, but currently asks the compiler to analyze
the program before it determines that information.
PR Close#40956
This commit moves a constant which is affected by a g3 sync patch into a
separate file. This way, changes to the rest of the compiler codebase have
no chance of conflicting with the patched code.
PR Close#40950
When certain information is requested from the Angular Language Service, we
know that there will be no additional Angular information if the requested
position is not in an inline template, template url, or style url. To avoid
unnecessary compiler compilations, we short circuit and return `undefined`
before asking the compiler for any type of answer which would trigger a
partial compilation, at the very least.
fixes https://github.com/angular/vscode-ng-language-service/issues/1104
PR Close#40946
Before this change, when Google Chrome cancels a XMLHttpRequest, an Observable of the response
never finishes. This happens, for example, when you put your computer to sleep or just press
Ctrl+S to save the browser page. After this commit, if request is canceled or aborted an
appropriate Observable will be completed with an error.
Fixes#22324
PR Close#40786
This commit updates compiler_spec.ts in the Ivy LS suite to utilize the new
testing environment which was introduced in the previous commit. Eventually
all specs should be converted, but converting one right now helps ensure
that the new testing env is working properly and able to support real tests.
PR Close#40679
The Ivy Language Service codebase testing suite contains a few testing
utilities which allow for assertions of Language Service operations against
an in-memory project. However, this existing utility lacks the flexibility
to test more complex scenarios, such as those involving multiple TS projects
with dependencies between them.
This commit introduces a new 'testing' package for the Ivy LS which attempts
to more faithfully represent the possible states of an IDE, and allows for
testing of more advanced scenarios. The new utility borrows from the prior
version and is geared towards more ergonomic testing. Only basic
functionality is present in this initial implementation, but this will grow
over time.
PR Close#40679
This PR performs a small refactoring to use `RuntimeError` class and corresponding error code (by calling
`throwProviderNotFoundError` which formats the message) to make it more consistent with other places where
similar errors are thrown.
PR Close#40901
Previously, in order to apply some styles to marketing (i.e. non-docs)
pages, we listed the various `.page-*` classes that corresponded to docs
pages. This meant that adding/removing a marketing page required updates
in several places, which is error-prone.
This commit avoids this by using a Sass mixin for applying styles to
marketing pages.
PR Close#40881
Previously, some of the marketing pages had different styles for the
top-nav than others (even if they had the same layout and
blue-background header). More specifically, the top-nav had a box-shadow
and it was absolutely positioned on some marketing pages, while it had
no box-shadow and was statically positioned on others.
This commit makes the appearance of marketing pages wrt the top-nav
consistent across all marketing pages by changing the styles for the
remaining pages:
- Contributors (`/about`)
- Contribute (`/contribute`)
- Press kit (`/presskit`)
Before: ![contribute topnav shadow before][1]
After: ![contribute topnav shadow after][2]
[1]: https://user-images.githubusercontent.com/8604205/107984898-a6aaee00-6fd1-11eb-8bf3-79393c8983ff.png
[2]: https://user-images.githubusercontent.com/8604205/107984900-a7438480-6fd1-11eb-8d9b-a643d69ab692.png
PR Close#40881
Previously, in order to apply some styles to docs (i.e. non-marketing)
pages, we listed the various `.folder-*` classes that corresponded to
docs pages. This meant that adding/removing a docs area required updates
in several places, which is error-prone.
This commit avoids this by using a Sass mixin for applying styles to
docs pages.
PR Close#40881
This commit removes some unnecessary styles setting `font-family` to
`$main-font`. These styles are redundant, because the targeted elements
already inherit this style from `<body>`.
PR Close#40881
This commit removes some CSS rules targeting `.doc-version select` in
the sidenav. These rules do not match any elements any more, since now
we use a custom `<aio-select>` component (instead of the `<select>`
element).
PR Close#40881
Previously, some of the links on the error pages had URLs prefixed with
`https://angular.io/`. This caused them to be treated as external URLs,
which had the following downsides:
- Links would always point to `angular.io` instead of the same version
as the error page (e.g. `next.angular.io` or `v11.angular.io`).
- Dgeni would not be able to check that the URLs are valid (i.e. point
to existing pages).
- An external link icon would incorrectly be shown next to the links on
`angular.io`.
This commit fixes the links to use relative URLs.
PR Close#40881
Currently, the function that is provided through `HAMMER_LOADER` is called the
same number of times as the `HammerGesturesPlugin.addEventListener` method is called
(until the Hammer is loaded).
This commit adds a class property in which the loader call is saved, thereby
preventing multiple calls to the loader function.
PR Close#25995
PR Close#40911
Previously we were calling `updateSourceLocations()` as part of
`extractMessages()` for every file that was passed in, regardless of
whether any `$localize` tagged strings were to be found in the file.
This was very wasteful because it is non-trivial to compute the flattened
source-map for files if it is not needed.
PR Close#40891
Beginning with rules_nodejs@3.0.0, strict visibility defaults to true. This means
that we are no longer, in bazel dependencies, able to depend on a package which was
transitively depended on from another dependency we do have in our package.json
PR Close#40895
This commit adds `ngDevMode` guard to show the warning only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The `ngDevMode` flag helps to tree-shake the warning from production builds
(in dev mode everything will work as it works right now) to decrease production bundle size.
PR Close#40876
Our approach for handling cyclic imports results in code that is
not easy to tree-shake, so it is not suitable for publishing in a
library.
When compiling in partial compilation mode, we are targeting
such library publication, so we now create a fatal diagnostic
error instead of trying to handle the cyclic import situation.
Closes#40678
PR Close#40782
ChromeDriver now supports Apple Silicon ARM processors.
`webdriver-manager` versions 12.1.7 and earlier will, however,
incorrectly download the arm64 ChromeDriver regardless of the
system's architecture. This results in failure to run Protractor tests
on macOS with the error: `spawn Unknown system error -86`
This commit fixes the problem by upgrading `webdriver-manager` to
version 12.1.8, which includes a fix.
See also https://stackoverflow.com/questions/65618558.
PR Close#40885
Previously, the paths to some local dependencies in the `ivy-i18n`
integration project were pointing to non-generic bazel files that would
normally not exist on a user's machine.
This commit changes these paths to relative paths pointing to build
artifacts that are guaranteed to exist (once the necessary build
commands have been executed).
PR Close#40885
Fix router to ensure that a route module is only loaded once especially
in relation to the use of preload strategies with delayed or partial
loading.
Add test to check the interaction of PreloadingStrategy and normal
router navigation under differing scenarios.
Checking:
* Prevention of duplicate loading of modules.
related to #26557
* Prevention of duplicate RouteConfigLoad(Start|End) events
related to #22842
* Ensuring preload strategy remains active for submodules if needed
The selected preload strategy should still decide when to load submodules
* Possibility of memory leak with unfinished preload subscription
related to #26557
* Ensure that the stored loader promise is cleared so that subsequent
load will try the fetch again.
* Add error handle error from loadChildren
* Ensure we handle error from with NgModule create
Fixes#26557#22842#26557
PR Close#40389
The previous commits refactored the `ShadowCss` emulator to support
desirable use-cases of `:host-context()`, but it dropped support
for passing a comma separated list of selectors to the `:host-context()` .
This commit rectifies that omission, despite the use-case not being
valid according to the ShadowDOM spec, to ensure backward compatibility
with the previous implementation.
PR Close#40494
In `ViewEncapsulation.Emulated` mode the compiler converts `:host` and
`:host-context` pseudo classes into new CSS selectors.
Previously, when there was both `:host-context` and `:host` classes in a
selector, the compiler was generating incorrect selectors. There are two
scenarios:
* Both classes are on the same element (i.e. not separated). E.g.
`:host-context(.foo):host(.bar)`. This setup should only match the
host element if it has both `foo` and `bar` classes. So the generated
CSS selector should be: `.foo.bar<hostmarker>`.
* The `:host` class is on a descendant of the `:host-context`. E.g.
`:host-context(.foo) :host(.bar)`. This setup should only match the
`.foo` selector if it is a proper ancestor of the host (and not on the
host itself). So the generated CSS selector should be:
`.foo .bar<hostmarker>`.
This commit fixes the generation to handle these scenarios.
Fixes#14349
PR Close#40494
In `ViewEncapsulation.Emulated` mode, the compiler must generate additional
combinations of selectors to handle the `:host-context()` pseudo-class function.
Previously, when there is was more than one `:host-context()` selector in a
rule, the compiler was generating invalid selectors.
This commit generates all possible combinations of selectors needed to
match the same elements as the native `:host-context()` selector.
Fixes#19199
PR Close#40494
In #40419 we move the code that creates the `heroes` object
above the code that updates the message service. But this moved
that line of code outside of the docregion that is displayed in
the tutorial ealier on, making it non-sensical.
This commit ensures that this line of code is now rendered in the
tutorial be moving it within the correct docregion.
Closes#40788
PR Close#40789
On larger screens the top-bar has a height of 64px. On screens smaller
than 600px, the top-bar has a height of 56px. As a result, the sidenav
should have a top position of 56px on screens smaller than 600px and
64px on other screens.
Previously, the style setting the top position to 56px was tied to the
presence of the `.collapsed` class, which depends on whether the sidenav
is docked or not. The change from docked to collapsed sidenav, however,
happens at 992px. As a result, the sidenav had an incorrect top position
(56px instead of 64px) on screens between 600px and 991px.
This commit fixes this by ensuring the change of the top position for
the sidenav happens at 600px.
PR Close#40802
Both `CodeExampleComponent` and `CodeTabsComponent` components receive
some code via content projection, grab the projected content and pass it
through to a `CodeComponent` instance for formatting and displaying.
Previously, the projected content was kept in the DOM (hidden). This
unnecessarily increased the number of DOM nodes.
This commit fixes this by clearing the projected DOM nodes once their
content has been captured.
PR Close#40802
Update the HTTP guide and associated example to demonstrate
how an interceptor can be used to provide a custom JSON parser.
Resolves#21079
PR Close#40645
After the docs UI redesign `h2` tags got a border top.
`border-top: 1px solid #dbdbdb;`;
In the sections of Getting Started guide in order to separate
`What's next` from above content an `<hr />` tag was used,
that now becomes unnecessary.
This commit removes unnecessary `<hr />` tags.
PR Close#40693
The "Usage Notes" section is often at the bottom of a long page of content
which can make it difficult to discover. This commit adds a link at the
end of the "Description" if there is a "Usage Notes" section on the page.
This link should help the reader to discover that there is more information
available further down the page.
This is basically a marginal fix. The longer term fix should be to
consider what content goes in which sections and how they should
be laid out on the page.
See #40753
PR Close#40835
The CDK has had a service for copying strings to the clipboard. These changes switch
AIO to it, rather than having to maintain a custom solution.
PR Close#40840
In Chrome 83 passing a TrustedScript to eval just returns the
TrustedScript back without evaluating it, causing the
newTrustedFunctionFor{Dev,JIT} functions to fail. This is a browser bug
that has been fixed in Chrome 84, and only affects Angular applications
running with JIT (which includes unit tests).
As a temporary workaround for users still on Chrome 83, detect when this
occurs in the newTrustedFunctionFor* functions and fall back to the
straightforward, non-Trusted Types compatible implementation. The only
combination that is left affected consists of Angular applications
running with JIT, that have explicitly configured Trusted Types in
enforcement mode, with users that are still on Chrome 83.
Also correct docstring for newTrustedFunctionForJIT.
PR Close#40815
Initially raised due to #39509, this change updates our
"Support policy and schedule" with the same disclaimer
from the "Release frequency" section above.
PR Close#40770
This commit implements creating of `ɵɵngDeclarePipe()` calls in partial
compilation, and processing of those calls in the linker and JIT compiler.
See #40677
PR Close#40803
The removed bit was copied and pasted from a previous section. Not relevent for the particular step of the tutorial.
The removed bit can we found as intended in __Adding Navigation__ section.
PR Close#40812
This commit causes imports added by ngtsc's `ImportManager` to have their
TypeScript "original node" set to the generated `ts.ImportDeclaration`
statement.
In g3, the tsickle transformer runs after the Angular transformer and post-
processes Angular's compilation output. One of its post-processing tasks is
to transform generated imports and references to imported symbols from the
commonjs module system to the g3 module system. Part of this transformation
involves recognizing modules with specific metadata and altering references
to symbols from those modules accordingly.
Normally, tsickle can rely on TypeScript's binding for an imported symbol to
find its origin module and thus the correct metadata for the symbol. However
the Angular transform generates new synthetic imports which don't have such
binding information. Angular's imports are always namespace imports of the
form:
```
import * as qualifier 'module/specifier';
```
References to such an import are then of the form `qualifier.SymbolName`.
To process such imports properly, tsickle needs to be able to associate the
reference to `qualifier` in the expression `qualifer.SymbolName` with the
`ts.ImportDeclaration` statement that defines it. It expects to do this by
looking at the `ts.getOriginalNode()` for the `qualifier` reference, which
should be the `ts.ImportDeclaration`. This commit changes ngtsc's import
generation mechanism to set the original node on `qualifier` identifiers
according to this expectation.
This commit is not tested in the direct compiler tests, since:
1) there is no observable behavior externally from setting the original node
2) we don't have tests that intercept transformer operations (which could be
used to directly assert against the AST nodes)
3) tsickle's published version does not (yet) contain the g3-specific
transformations which rely on the original node and would thus allow the
behavior to be observed.
Instead, we rely on the g3 testing suite to validate the correctness of this
fix. Breaking this functionality would cause g3 compilation errors for
targets, since tsickle would be unable to transform imports correctly.
PR Close#40711
Removes BES configuration from CI bazel configuration as it is increasingly seeing timeouts
causing failures, but the uploaded results go largely unlooked at.
PR Close#40809
Fix router to ensure that a route module is only loaded once especially
in relation to the use of preload strategies with delayed or partial
loading.
Add test to check the interaction of PreloadingStrategy and normal
router navigation under differing scenarios.
Checking:
* Prevention of duplicate loading of modules.
related to #26557
* Prevention of duplicate RouteConfigLoad(Start|End) events
related to #22842
* Ensuring preload strategy remains active for submodules if needed
The selected preload strategy should still decide when to load submodules
* Possibility of memory leak with unfinished preload subscription
related to #26557
* Ensure that the stored loader promise is cleared so that subsequent
load will try the fetch again.
* Add error handle error from loadChildren
* Ensure we handle error from with NgModule create
Fixes#26557#22842#26557
PR Close#40389
When using the [timeout attribute](https://xhr.spec.whatwg.org/#the-timeout-attribute) and an XHR
request times out, browsers trigger the `timeout` event (and execute the XHR's `ontimeout`
callback). Additionally, Safari 9 handles timed-out requests in the same way, even if no `timeout`
has been explicitly set on the XHR.
In the above cases, `HttpClient` would fail to capture the XHR's completing (with an error), so
the corresponding `Observable` would never complete.
PR Close#40771
Update replacements of the `//dev-infra/` piece of bazel path segments to reference the `@npm//`
workspace rather than creating its own workspace.
PR Close#40785
Much like the compiler-cli, the language-service package has internal testing
tools that are not intended for external use and do not need fw-testing review.
See #40679.
PR Close#40795
Much like the compiler-cli, the language-service package has internal testing
tools that are not intended for external use and do not need fw-testing review.
See #40679.
PR Close#40787
The parser does not include parenthesis in the AST, so if a LHS
expression would be parenthesized then its start span would start
after the opening parenthesis. Previously, some parent AST nodes would
be created with the start span of its LHS as its own start, so this
resulted in the parent AST node not encompassing the opening parenthesis
in its source span. This commit fixes the issue by capturing the start
index prior to parsing a child AST tree, which is then used as the
start of the source span of the the parent AST node that is parsed.
Fixes#40721
PR Close#40740
In 5c547675b1 the `EventEmitter.subscribe`
API was extended with a new signature that allows the emitter's generic
type `T` to flow into the subscribe callback. This new signature removes
the need for the special `_outputHelper` function that used to be
emitted into TCBs when `strictOutputEventTypes`/`strictTemplates` is
enabled.
PR Close#40738
Adds an error if a reference is used more than once on the same element (e.g. `<div #a #a>`).
We used to have this error in ViewEngine, but it wasn't ported over to Ivy.
Fixes#40536.
PR Close#40538
Observables are not the only async mechanism that Angular employs.
This change respects that application developers are not required to
use Observables in their own application architecture.
Closes#39155
PR Close#39237
This commit fixes the issue of the ASSERTION ERROR issue when
a projected node(RNode) inside an array is checked against the types
of TNodeType.Element, TNodeType.Container, TNodeType.ElementContainer,
TNodeType.IcuContainer, TNodeType.Projection. As it's inside an array,
it doesn't fall into any of those types, as a result, it throws
the ASSERTION ERROR.
PR Close#37120
PR Close#37167
Produces a diagnostic when we cannot resolve a component's external style sheet or external template.
The previous behavior was to throw an exception, which crashed the
Language Service.
fixes angular/vscode-ng-language-service#1079
PR Close#40660
This is patch PR for #40621.
Two motivations behind this change:
1. We would like to expose the types of the Language Service to external
users (like the VSCode extension) via the npm package, on the top
level of the package
2. We would like the View Engine and Ivy LS to share a common interface
(notably after the inclusion of `getTcb`, the Ivy LS upholds a
strict superset of `ts.LanguageService`; previously both VE and Ivy
LS were aligned on `ts.LanguageService`.)
To this end, this commit refactors the exports on the toplevel of the
`language-service/` package to just be types common to both the VE and
Ivy language services. The VE and Ivy build targets then import and use
these types accordingly, and the expectation is that an external user
will just import the relevant typings from the toplevel package without
diving into either the VE or Ivy sources.
Follow up on #40607
PR Close#40773
This commit updates the documentation style guide
so that it is in line with current standards, those
of Google as well as those within the Angular docs.
PR Close#36281
When the downleveling helper function has been inlined into the
`$localize` call, it is a bit more tricky to parse out the cooked and
raw strings. There was already code to do this but it assumed that
the `cooked` and `raw` items were both arrays.
Sometimes the `raw` array is just a copy of the `cooked` array
via an expression similar to `raw || (raw=tcookedslice(0))`. This
commit changes the `unwrapMessagePartsFromLocalizeCall()`
function to be able to handle such a situation.
Fixes#40702
PR Close#40754
Previously, if an entry-point had no public exports (such as the
`@angular/platform-server/shims` introduced in #40559, which is a
side-effect-ful entry-point), it was incorrectly marked as having all
its exports deprecated (which marks the entry-point as deprecated as
well).
This commit fixes this by ensuring that an entry-point is not marked as
having all its exports deprecated if it has no public exports.
PR Close#40737
Previously if the code is invalid the error message might look like:
```
Unexpected messageParts for `$localize` (expected an array of strings).
```
This is not very helpful for debugging where the problem occurs.
Now we build a "code-frame" description to give more useful information:
```
TypeError: Cannot create property 'message' on string '.../src/app/app.component.js:
Unexpected messageParts for `$localize` (expected an array of strings).
4 | export class AppComponent {
5 | constructor() {
> 6 | this.title = $localize(a = ['myapp'], []);
| ^^^^^^^^^^^^^
7 | }
8 | }
```
PR Close#40724
Prior to this patch, if an element was removed multiple times (due
to the nature of parent/child elements), the leave listeners may
have been fired for an element that was already removed. This patch
adds a guard within the animations code to prevent this.
PR Close#40712
Previously, the API list container (in the template of the
`<aio-api-list>` component) had three different CSS classes
(`.api-list-container`, `.docs-content`, `.l-content-small`) that were
all used for styling it. This seemed unnecessary and made it more difficult
to see what styles were applied to the container.
This commit removes the extra classes and consolidates the styles under
the `.api-list-container` class (which was the most descriptive one).
PR Close#40704
This commit ensures that all styles for the API list page (which are
defined in `_api-list.scss`) only apply to elements inside an
`<aio-api-list>` element. This will prevent the styles accidentally
taking effect on a different part of the app.
PR Close#40704
The `.code-anchor` class can be used anywhere where we have code
examples (including API pages and docs guides). Previously, global
styles for `.code-anchor` were defined in `_api-list.scss` (i.e. the
styles from `_api-list.scss` were also applied to `.code-anchor`
elements in other pages/components).
This commit moves the `.code-anchor` styles to `_code.scss`, which
contains other common code-related styles.
PR Close#40704
The `.symbol` CSS class (which is primarily used to denote the type of
API symbols - classes, functions, interfaces, etc.) are used in several
places:
- In the API list page (with the corresponding styles defined in
`_api-list.scss`).
- In search results (with the corresponding styles defined in
`_errors.scss`).
- In error list page (with the corresponding styles defined in
`search-results.scss`).
- In the `<aio-select>` component (with the corresponding styles defined
in `_select-menu.scss`).
Previously, global styles for `.symbol` were defined in `_api-list.scss`
(i.e. the styles from `_api-list.scss` were also applied to `.symbol`
elements in other places/components). Also, some of the SCSS files
mentioned above defined some duplicate styles for `.symbol`.
This commit moves the `.symbol` styles to a new `_api-symbols.scss`
file, which contains common symbol-related styles.
PR Close#40704
This commit removes some styles from `_api-list.scss` that are no longer
used (i.e. either their CSS selectors do not match any element in the
app or they are overridden by other rules).
PR Close#40704
This commit ensures that all styles for the TOC (which are defined in
`_toc.scss`) only apply to elements inside an `<aio-toc>` element. This
will prevent the styles accidentally taking effect on a different part
of the app.
PR Close#40704
This commit ensures that all styles for the select-menu element (which
are defined in `_select-menu.scss`) only apply to elements inside an
`<aio-select>` element. This will prevent the styles accidentally taking
effect on a different part of the app.
PR Close#40704
This commit ensures that all styles for the "Resources" page (which are
defined in `_resources.scss`) only apply to elements inside an
`<aio-resource-list>` element. This will prevent the styles accidentally
taking effect on a different part of the app.
PR Close#40704
This commit removes some styles from `_resources.scss` that are no
longer used (i.e. either their CSS selectors do not match any element in
the app or they are overridden by other rules).
PR Close#40704
This commit removes some styles from `_label.scss` that are no longer
used (i.e. their CSS selectors do not match any element in the app).
PR Close#40704
This commit removes the `_edit-page-cta.scss` file, which is no longer
used (i.e. the rules it contains do not match any element in the app).
PR Close#40704
This commit cleans up the styles in `_details.scss` by merging
together blocks that target the same elements.
It also changes the `summary` selector to `details > summary`, but that
should not make any difference in practice, since `<summary>` elements
always appear as direct childs of `<details>`.
PR Close#40704
This commit ensures that all styles for the contributor list (which are
defined in `_contributor.scss`) only apply to elements inside an
`<aio-contributor-list>` element. This will prevent the styles
accidentally taking effect on a different part of the app.
PR Close#40704
This commit removes some styles from `_contributor.scss` that are no
longer used (i.e. either their CSS selectors do not match any element in
the app or they are overridden by other rules).
PR Close#40704
This commit ensures that all styles for the code examples (which are
defined in `_code.scss`) only apply to elements inside an `<aio-code>`
element. This will prevent the styles accidentally taking effect on a
different part of the app.
PR Close#40704
This commit cleans up the styles in `_code.scss` by merging together
blocks that target the same elements.
It also normalizes the rules targeting Angular Material tabs to use
consistent selectors and use class names instead of tag names.
PR Close#40704
This commit removes some styles from `_code.scss` that are no longer
used (i.e. either their CSS selectors do not match any element in the
app or they are overridden by other rules).
PR Close#40704
Both `<aio-contributor-list>` and `<aio-resource-list>` contain
`.group-buttons` elements. Previously, global styles for
`.group-buttons` were defined in `_contributor.scss` (i.e. the styles
from `_contributor.scss` were also applied to `.group-buttons` in
`<aio-resource-list>`). Also, `_contributor.scss` and `_resources.scss`
defined some duplicate styles for `.group-buttons`.
This commit moves the `.group-buttons` styles to `_buttons.scss`, which
contains common button-related styles.
PR Close#40704
This commit ensures that all styles for the app top-menu (which are
defined in `_top-menu.scss`) only apply to elements inside an
`.app-toolbar` element. This will prevent the styles accidentally taking
effect on a different part of the app.
PR Close#40704
This commit cleans up the styles in `_top-menu.scss` by merging
together blocks that target the same elements.
It also makes similar changes to selectors in `_notification.scss` rules
that override top-menu styles (for consistency).
PR Close#40704
This commit ensures that all styles for the sidenav nav-items (which are
defined in `_sidenav.scss`) only apply to elements inside an
`<aio-nav-item>` element. This will prevent the styles accidentally
taking effect on a different part of the app.
PR Close#40704
This commit cleans up the styles in `_sidenav.scss` by merging
together blocks that target the same elements.
It also applies the equivalent changes in `_notification.scss` rules
that override sidenav styles.
PR Close#40704
This commit removes some styles from `_sidenav.scss` that are no longer
used (i.e. either their CSS selectors do not match any element in the
app or they are overridden by other rules).
PR Close#40704
This commit removes some styles from `_layout-global.scss` that are no
longer used (i.e. either their CSS selectors do not match any element in
the app or they are overridden by other rules).
PR Close#40704
This commit ensures that all styles for the page footer (which are
defined in `_footer.scss`) only apply to elements inside an
`<aio-footer>` element. This will prevent the styles accidentally taking
effect on a different part of the app.
PR Close#40704
This commit removes some styles from `_footer.scss` that are no longer
used (i.e. either their CSS selectors do not match any element in the
app or they are overridden by other rules).
PR Close#40704
This commit removes some styles from `_content-layout.scss` that are no
longer used (i.e. either their CSS selectors do not match any element in
the app or they are overridden by other rules).
PR Close#40704
No longer emits to `Router.events` after the router has been destroyed. Also
returns a resolved promise to the navigation methods.
Fixes#40502.
PR Close#40638
This commit updates `AbstractControlStatus` directive code to remove duplicated logic in getters and replaces
that logic with a new function that accepts an argument.
PR Close#40651
The `AsyncPipe.transform<T>(emitter)` method must infer the `T`
type from the `emitter` parameter. Since we changed the `AsyncPipe`
to expect a `Subscribable<T>` rather than `Observable<T>` the
`EventEmitter.subscribe()` method needs to have a tighter signature.
Otherwise TypeScript struggles to infer the type and ends up making
it `unknown`.
Fixes#40637
PR Close#40644
The `TemplateTypeChecker.overrideComponentTemplate` operation was originally
conceived as a "fast path" for the Language Service to react to a template
change without needing to go through a full incremental compilation step. It
served this purpose until the previous commit, which switches the LS to use
the new resource-only incremental change operation provided by `NgCompiler`.
`overrideComponentTemplate` is now no longer utilized, and is known to have
several hard-to-overcome issues that prevent it from being useful in any
other situations. As such, this commit removes it entirely.
PR Close#40585
This commit changes the Language Service's "compiler factory" mechanism to
leverage the new resource-only update path for `NgCompiler`. When an
incoming change only affects a resource file like a component template or
stylesheet, going through the new API allows the Language Service to avoid
unnecessary incremental steps of the `NgCompiler` and return answers more
efficiently.
PR Close#40585
This commit removes some styles for the `.heading` CSS class which do
not have any effect (either because they are overridden in other rules
or because they do not make any difference).
NOTE:
The `.heading` class is kept in the HTML to make it easier to associate
the `.heading-children` element with its corresponding `.heading`
parent.
PR Close#40427
This commit simplifies the styling of the "collapsed/expanded" icons in
sidenav nav-items with children by consolidating the CSS rules in one
block (instead of having duplicate blocks for different levels).
PR Close#40427
This commit fixes the layout and appearance of the cards shown in the
docs introduction page (`/docs`) in the following ways:
- Center the cards.
- Ensure two cards are shown per line (instead of 3 one the first line
and 1 on the second).
- Adjust their widths to ensure their content fits well in them
(given that the cards have a fixed height).
- Use more engaging styles to better indicate that the cards are
clickable (as discussed [here][1]).
[1]: https://github.com/angular/angular/pull/40427#discussion_r560688953
PR Close#40427
This commit cleans up the styles in `_card.scss` by:
- Fixing incosistenct indentation/newlines.
- Removing rules for unused selectors.
- Removing unnecessary styles.
PR Close#40427
This commit changes the layout of the main content to improve
legibility, especially on wider screens:
- Limit main content width to 50em (800px by default).
- Center main content on the page.
Co-authored-by: Stefanie Fluin <sjtrimble@gmail.com>
PR Close#40427
This commit includes some general improvements to heading styles
(font-weight, margin/padding). It also adds a horizontal separator above
`<h2>` headings to segment important sections more easily.
(As a consequence, we can remove several `<hr />` elements right before
`<h2>` headings.)
Co-authored-by: Stefanie Fluin <sjtrimble@gmail.com>
PR Close#40427
This commit improves the padding nav-menus and nav-items in the sidenav.
It also ensures that all nav-items have the same height, regardless of
their level and of whether they have children or not.
Co-authored-by: Stefanie Fluin <sjtrimble@gmail.com>
PR Close#40427
Previously, we used a box-shadow to indicate that the sidenav is
separate from the main content.
This commits updates the sidenav styling to remove the shadow and give
it a slightly different background color instead.
Co-authored-by: Stefanie Fluin <sjtrimble@gmail.com>
PR Close#40427
Normally the template parsing operation normalizes all template line endings
to '\n' only. This normalization operation causes source mapping errors when
the original template uses '\r\n' line endings.
The compiler already parses templates again to create a "diagnostic"
template AST with accurate source maps, to avoid other parsing issues that
affect source map accuracy. This commit configures this diagnostic parse to
also preserve line endings.
PR Close#40597
In b6cd38ff05 we fixed the DatePipe so
that when it parsed date strings that looked like `YYYY-MM` it created a UTC
date that was not affected by the local timezone of the JavaScript engine.
This commit does the same for date strings of the form `YYYY`.
(Note that the previous commit, mentioned above, attempted to fix this case
too but the test was not actually checking the correct input string.)
Fixes#33944
PR Close#40620
PR Close#40629
In 2aba8b0 we fixed the DatePipe so that when it parsed date strings
that looked like `YYYY-MM-DD` it created a UTC date that was not
affected by the local timezone of the JavaScript engine.
This commit does the same for date strings of the form `YYYY-MM`
and `YYYY`.
Fixes#33944
PR Close#40620
When parsing interpolations, if we encounter an empty interpolation
(`{{}}`), the current code uses a "pretend" value of `$implicit` for the
name as if the interplotion were really `{{$implicit}}`. This is
problematic because the spans are then incorrect downstream since they
are based off of the `$implicit` text.
This commit changes the interpretation of empty interpolations so that
the text is simply an empty string.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1077
Fixes https://github.com/angular/vscode-ng-language-service/issues/1078
PR Close#40583
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
If the template parse option `leadingTriviaChars` is configured to
consider whitespace as trivia, any trailing whitespace of an element
would be considered as leading trivia of the subsequent element, such
that its `start` span would start _after_ the whitespace. This means
that the start span cannot be used to mark the end of the current
element, as its trailing whitespace would then be included in its span.
Instead, the full start of the subsequent element should be used.
To harden the tests that for the Ivy parser, the test utility `parseR3`
has been adjusted to use the same configuration for `leadingTriviaChars`
as would be the case in its production counterpart `parseTemplate`. This
uncovered another bug in offset handling of the interpolation parser,
where the absolute offset was computed from the start source span
(which excludes leading trivia) whereas the interpolation expression
would include the leading trivia. As such, the absolute offset now also
uses the full start span.
Fixes#39148
PR Close#40513
The codebase currently contains several `EMPTY_ARRAY` constants,
and they can end up in the bundle of an application.
A recent commit 6fbe219 tipped us off
as it introduced several `noop` occurrences in the golden symbol files.
After investigating with @petebacondarwin,
we decided to remove the duplicated symbols.
This probably shaves only a few bytes,
but this commit removes the duplicated functions,
by always using the one in `core/src/utils/empty`.
PR Close#40587
# **NOTE 1**: Pin to exact images using an ID (SHA). See https://circleci.com/docs/2.0/circleci-images/#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version.
# (Using the tag in not necessary when pinning by ID, but include it anyway for documentation purposes.)
# **NOTE 2**: If you change the version of the docker images, also change the `cache_key` suffix.
# VSCode Remote Development - Developing inside a Container
# VSCode Remote Development - Developing inside a Containers
This folder contains configuration files that can be used to opt into working on this repository in a [Docker container](https://www.docker.com/resources/what-container) via [VSCode](https://code.visualstudio.com/)'s Remote Development feature (see below).
@@ -12,7 +12,7 @@ Info on remote development and developing inside a container with VSCode:
_Prerequisite: [Install Docker](https://docs.docker.com/install) on your local environment._
To get started, read and follow the instructions in [Developing inside a Container](https://code.visualstudio.com/docs/remote/containers). The [.devcontainer/](.) directory contains pre-configured `devcontainer.json` and `Dockerfile` files, which you can use to set up remote development with a docker container.
To get started, read and follow the instuctions in [Developing inside a Container](https://code.visualstudio.com/docs/remote/containers). The [.devcontainer/](.) directory contains pre-configured `devcontainer.json` and `Dockerfile` files, which you can use to set up remote development with a docker container.
In a nutshell, you need to:
- Install the [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension.
pendingDesc:"Googler: run g3sync presubmit {{PRNumber}}"
# text to show when the status is success
successDesc:'Does not affect google3'
successDesc:"Does not affect google3"
# link to use for the details
url:'http://go/angular/g3sync'
url:"http://go/angular/g3sync"
# list of patterns to check for the files changed by the PR
# this list must be manually kept in sync with google3/third_party/javascript/angular2/copy.bara.sky
include:
- "LICENSE"
- "modules/benchmarks/**"
- "modules/system.d.ts"
- "packages/**"
- "dev-infra/benchmark/driver-utilities/**"
# list of patterns to ignore for the files changed by the PR
exclude:
- "packages/*"
- "packages/bazel/*"
- "packages/bazel/src/api-extractor/**"
- "packages/bazel/src/builders/**"
- "packages/bazel/src/ng_package/**"
- "packages/bazel/src/protractor/**"
- "packages/bazel/src/schematics/**"
- "packages/compiler-cli/src/ngcc/**"
- "packages/compiler-cli/linker/**"
- "packages/compiler-cli/ngcc/**"
- "packages/compiler-cli/src/ngtsc/sourcemaps/**"
- "packages/docs/**"
- "packages/elements/schematics/**"
- "packages/examples/**"
- "packages/language-service/**"
- "packages/localize/**"
- "packages/private/**"
- "packages/service-worker/**"
- "packages/common/locales/**"
- "packages/http/**"
- "**/.gitignore"
- "**/.gitkeep"
- "**/yarn.lock"
- "**/package.json"
- "**/third_party/**"
- "**/tsconfig-build.json"
- "**/tsconfig.json"
- "**/rollup.config.js"
- "**/BUILD.bazel"
- "**/*.md"
- "packages/**/integrationtest/**"
- "packages/**/test/**"
- "packages/zone.js/*"
- "packages/zone.js/dist/**"
- "packages/zone.js/doc/**"
- "packages/zone.js/example/**"
- "packages/zone.js/scripts/**"
# comment that will be added to a PR when there is a conflict, leave empty or set to false to disable
mergeConflictComment:"Hi @{{PRAuthor}}! This PR has merge conflicts due to recent upstream merges.\nPlease help to unblock it by resolving these conflicts. Thanks!"
# label to monitor
mergeLabel: 'action:merge'
mergeLabel:"action: merge"
# adding any of these labels will also add the merge label
mergeLinkedLabels:
- 'action:merge-assistance'
- "action: merge-assistance"
# list of checks that will determine if the merge label can be added
checks:
# require that the PR has reviews from all requested reviewers
#
# This enables us to request reviews from both eng and tech writers, or multiple eng folks, and prevents accidental merges.
@@ -55,26 +100,34 @@ merge:
# whether the PR shouldn't have a conflict with the base branch
noConflict:true
# list of labels that a PR needs to have, checked with a regexp.
# list of labels that a PR needs to have, checked with a regexp (e.g. "target:" will work for the label "target: master")
requiredLabels:
- 'target:*'
- "target: *"
- "cla: yes"
# list of labels that a PR shouldn't have, checked after the required labels with a regexp
forbiddenLabels:
- 'target:TBD'
- 'action:cleanup'
- 'action:review'
- 'state:blocked'
- "target: TBD"
- "action: cleanup"
- "action: review"
- "state: blocked"
- "cla: no"
# list of PR statuses that need to be successful
requiredStatuses:
- 'google-internal-tests'
- 'pullapprove'
- "ci/circleci: build"
- "ci/circleci: lint"
- "ci/circleci: publish_snapshot"
- "ci/angular: size"
- "cla/google"
- "google3"
- "pullapprove"
# the comment that will be added when the merge label is added despite failing checks, leave empty or set to false to disable
# {{MERGE_LABEL}} will be replaced by the value of the mergeLabel option
# {{PLACEHOLDER}} will be replaced by the list of failing checks
mergeRemovedComment:"I see that you just added the `{{MERGE_LABEL}}` label, but the following checks are still failing:\n{{PLACEHOLDER}}\n\n**If you want your PR to be merged, it has to pass all the CI checks.**\n\nIf you can't get the PR to a green state due to flakes or broken `main`, please try rebasing to `main` and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help."
mergeRemovedComment:"I see that you just added the `{{MERGE_LABEL}}` label, but the following checks are still failing:\n{{PLACEHOLDER}}\n\n**If you want your PR to be merged, it has to pass all the CI checks.**\n\nIf you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help."
# options for the triage plugin
triage:
@@ -84,29 +137,40 @@ triage:
defaultMilestone:82,
# arrays of labels that determine if an issue has been triaged by the caretaker
l1TriageLabels:
- - 'area:*'
-
- "comp: *"
# arrays of labels that determine if an issue has been fully triaged
l2TriageLabels:
- - 'P0'
- 'area:*'
- - 'P1'
- 'area:*'
- - 'P2'
- 'area:*'
- - 'P3'
- 'area:*'
- - 'P4'
- 'area:*'
- - 'P5'
- 'area:*'
- - 'feature'
- 'area:*'
- - 'discussion'
- 'area:*'
- - 'needs clarification'
- 'area:*'
- - 'needs reproduction'
- 'area:*'
-
- "P0"
- "comp: *"
-
- "P1"
- "comp: *"
-
- "P2"
- "comp: *"
-
- "P3"
- "comp: *"
-
- "P4"
- "comp: *"
-
- "P5"
- "comp: *"
-
- "feature"
- "comp: *"
-
- "discussion"
- "comp: *"
-
- "needs clarification"
- "comp: *"
-
- "needs reproduction"
- "comp: *"
# options for the triage PR plugin
triagePR:
@@ -118,14 +182,16 @@ triagePR:
defaultMilestone:82,
# arrays of labels that determine if a PR has been triaged by the caretaker
l1TriageLabels:
- - 'area:*'
-
- "comp: *"
# arrays of labels that determine if a PR has been fully triaged
l2TriageLabels:
- - 'area:*'
-
- "comp: *"
# options for rerunning CI
rerunCircleCI:
# set to true to disable
disabled:false
# the label which when added triggers a rerun of the default CircleCI workflow
@@ -6,15 +6,15 @@ This folder contains opt-in [Workspace Settings](https://code.visualstudio.com/d
To use the recommended configurations follow the steps below:
- install the recommended extensions in `.vscode/extensions.json`
- install the recommneded extensions in `.vscode/extensions.json`
- copy (or link) `.vscode/recommended-settings.json` to `.vscode/settings.json`
- copy (or link) `.vscode/recommended-launch.json` to `.vscode/launch.json`
- copy (or link) `.vscode/recommended-tasks.json` to `.vscode/tasks.json`
- restart the editor
If you already have your custom workspace settings, you should instead manually merge the file contents.
If you already have your custom workspace settings you should instead manually merge the file contents.
This isn't an automatic process, so you will need to repeat it when settings are updated.
This isn't an automatic process so you will need to repeat it when settings are updated.
To see the recommended extensions select "Extensions: Show Recommended Extensions" in the [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette).
@@ -22,4 +22,4 @@ To see the recommended extensions select "Extensions: Show Recommended Extension
If you wish to add extra configuration items please keep in mind any modifications you make here will be used by many users.
Try to keep these settings/configurations to things that help facilitate the development process and avoid altering the user workflow whenever possible.
Try to keep these settings/configuations to things that help facilitate the development process and avoid altering the user workflow whenever possible.
As contributors and maintainers of the Angular project, we pledge to respect everyone who contributes by posting issues, updating documentation, submitting pull requests, providing feedback in comments, and any other activities.
In the interest of fostering a safe and welcoming environment, we as
the Angular team pledge to make participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity, gender expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
Communication through any of Angular's channels (GitHub, Discord, Gitter, IRC, mailing lists, Twitter, etc.) must be constructive and never resort to personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
## Our Standards
We promise to extend courtesy and respect to everyone involved in this project regardless of gender, gender identity, sexual orientation, disability, age, race, ethnicity, religion, or level of experience. We expect anyone contributing to the Angular project to do the same.
Examples of behavior that contributes to creating a positive environment
include:
If any member of the community violates this code of conduct, the maintainers of the Angular project may take action, removing issues, comments, and PRs or blocking accounts as deemed appropriate.
* Use welcoming and inclusive language
* Respect each other
* Provide and gracefully accept constructive criticism
* Show empathy towards other community members
Examples of unacceptable behavior by participants include:
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* The use of sexualized language or imagery
* Unwelcome sexual attention or advances
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Angular team are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Angular team have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, and to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies to all Angular communication channels - online or in person,
and it also applies when an individual is representing the project or its community in
public spaces. Examples of representing a project or community include using an official
project e-mail address, posting via an official social media account, or acting
as an appointed representative at an online or offline event. Representation of
a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the Angular team at conduct@angular.io. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The Angular team
will maintain confidentiality with regard to the reporter of an incident.
Enforcement may result in an indefinite ban from all official Angular communication
channels, or other actions as deemed appropriate by the Angular team.
Angular maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
### Appeal
If you are banned you may contest the decision. To do so email conduct@angular.io with the subject line "Repeal Ban for {{your name here}}" and body with the responses to the following:
* Why do you believe you did not violate the Code of Conduct?
* Were other factors involved in this situation the leadership team may have been unaware of?
* Why do you wish to be a part of the Angular community?
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
If you are subject to or witness unacceptable behavior, or have any other concerns, please email us at [conduct@angular.io](mailto:conduct@angular.io).
@@ -58,9 +58,9 @@ If you would like to *implement* a new feature, please consider the size of the
### <a name="submit-issue"></a> Submitting an Issue
Before you submit an issue, please search the issue tracker. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.
Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
We want to fix all the issues as soon as possible, but before fixing a bug, we need to reproduce and confirm it.
We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it.
In order to reproduce bugs, we require that you provide a minimal reproduction.
Having a minimal reproducible scenario gives us a wealth of important information without going back and forth to you with additional questions.
@@ -68,7 +68,7 @@ A minimal reproduction allows us to quickly confirm a bug (or point out a coding
We require a minimal reproduction to save maintainers' time and ultimately be able to fix more bugs.
Often, developers find coding problems themselves while preparing a minimal reproduction.
We understand that sometimes it might be hard to extract essential bits of code from a larger codebase, but we really need to isolate the problem before we can fix it.
We understand that sometimes it might be hard to extract essential bits of code from a larger codebase but we really need to isolate the problem before we can fix it.
Unfortunately, we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you, we are going to close an issue that doesn't have enough info to be reproduced.
@@ -89,12 +89,12 @@ Before you submit your Pull Request (PR) consider the following guidelines:
We cannot accept code without a signed CLA.
Make sure you author all contributed Git commits with email address associated with your CLA signature.
4.[Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the angular/angular repo.
4.Fork the angular/angular repo.
5.In your forked repository, make your changes in a new git branch:
5.Make your changes in a new git branch:
```shell
git checkout -b my-fix-branch main
git checkout -b my-fix-branch master
```
6. Create your patch, **including appropriate test cases**.
@@ -109,7 +109,7 @@ Before you submit your Pull Request (PR) consider the following guidelines:
```shell
git commit --all
```
Note: the optional commit `--all` command line option will automatically "add" and "rm" edited files.
Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
10. Push your branch to GitHub:
@@ -117,7 +117,7 @@ Before you submit your Pull Request (PR) consider the following guidelines:
git push origin my-fix-branch
```
11. In GitHub, send a pull request to `angular:main`.
11. In GitHub, send a pull request to `angular:master`.
### Reviewing a Pull Request
@@ -181,10 +181,10 @@ After your pull request is merged, you can safely delete your branch and pull th
git push origin --delete my-fix-branch
```
* Check out the main branch:
* Check out the master branch:
```shell
git checkout main -f
git checkout master -f
```
* Delete the local branch:
@@ -193,10 +193,10 @@ After your pull request is merged, you can safely delete your branch and pull th
git branch -D my-fix-branch
```
* Update your local `main` with the latest upstream version:
* Update your master with the latest upstream version:
```shell
git pull --ff upstream main
git pull --ff upstream master
```
@@ -235,6 +235,8 @@ When the body is present it must be at least 20 characters long and must conform
The `footer` is optional. The [Commit Message Footer](#commit-footer) format describes what the footer is used for and the structure it must have.
Any line of the commit message cannot be longer than 100 characters.
@@ -260,7 +262,7 @@ The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is opti
Must be one of the following:
* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* **ci**: Changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)
* **ci**: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
@@ -300,13 +302,15 @@ There are currently a few exceptions to the "use package name" rule:
* `changelog`: used for updating the release notes in CHANGELOG.md
* `dev-infra`: used for dev-infra related changes within the directories /scripts and /tools
* `dev-infra`: used for dev-infra related changes within the directories /scripts, /tools and /dev-infra
* `docs-infra`: used for docs-app (angular.io) related changes within the /aio directory of the repo
* `migrations`: used for changes to the `ng update` migrations.
* `devtools`: used for changes in the [browser extension](./devtools/README.md).
* `ngcc`: used for changes to the [Angular Compatibility Compiler](./packages/compiler-cli/ngcc/README.md)
* `ve`: used for changes specific to ViewEngine (legacy compiler/renderer).
* none/empty string: useful for `test` and `refactor` changes that are done across all packages (e.g. `test: add missing unit tests`) and for docs changes that are not related to a specific package (e.g. `docs: fix typo in tutorial`).
@@ -330,8 +334,7 @@ You can include a comparison of the previous behavior with the new behavior in o
The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to.
For example:
The footer can contain information about breaking changes and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to.
Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
### Revert commits
@@ -390,10 +380,10 @@ The following documents can help you sort out issues with GitHub accounts and mu
@@ -59,26 +53,6 @@ Get started with Angular, learn the fundamentals and explore advanced topics on
- [Server Side Rendering][ssr]
- [Schematics][schematics]
- [Lazy Loading][lazyloading]
- [Animations][animations]
### Local Development
To contribute to Angular docs, you can setup a local environment with the following commands:
```bash
# Clone Angular repo
git clone https://github.com/angular/angular.git
# Navigate to project directory
cd angular
# Install dependencies
yarn
# Build and run local dev server
# Note: Initial build will take some time
yarn docs
```
## Development Setup
@@ -134,11 +108,11 @@ Check out our [upgrade guide](https://update.angular.io/) to find out the best w
### Contributing Guidelines
Read through our [contributing guidelines][contributing] to learn about our submission process, coding rules, and more.
Read through our [contributing guidelines][contributing] to learn about our submission process, coding rules and more.
### Want to Help?
Want to report a bug, contribute some code, or improve the documentation? Excellent! Read up on our guidelines for [contributing][contributing] and then check out one of our issues labeled as <kbd>[help wanted](https://github.com/angular/angular/labels/help%20wanted)</kbd> or <kbd>[good first issue](https://github.com/angular/angular/labels/good%20first%20issue)</kbd>.
Want to file a bug, contribute some code, or improve documentation? Excellent! Read up on our guidelines for [contributing][contributing] and then check out one of our issues in the [hotlist: community-help](https://github.com/angular/angular/labels/hotlist%3A%20community-help).
### Code of Conduct
@@ -148,7 +122,7 @@ Help us keep Angular open and inclusive. Please read and follow our [Code of Con
Join the conversation and help the community.
- [X (formerly Twitter)][X (formerly Twitter)]
- [Twitter][twitter]
- [Discord][discord]
- [Gitter][gitter]
- [YouTube][youtube]
@@ -160,27 +134,26 @@ Join the conversation and help the community.
**Love Angular? Give our repo a star :star: :arrow_up:.**
Angular is part of Google [Open Source Software Vulnerability Reward Program](https://bughunters.google.com/about/rules/6521337925468160/google-open-source-software-vulnerability-reward-program-rules). For vulnerabilities in Angular, please submit your report [here](https://bughunters.google.com/report).
For more information, check out [Angular's security policy](https://angular.io/guide/security).
* Map of the previews components, values are functions which returns the promise of the component type, which will be displayed as preview in the ExampleViewer component.
* Keys has to be equal to paths written down in the docs markdown files.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.