These token interfaces will make it easier to reason about tokens in the
parser and in specs.
Previously, it was never clear what items could appear in the `parts`
array of a token given a particular `TokenType`. Now, each token interface
declares a labelled tuple for the parts, which helps to document the token
better.
PR Close#43132
Previously, the way templates were tokenized meant that we lost information
about the location of interpolations if the template contained encoded HTML
entities. This meant that the mapping back to the source interpolated strings
could be offset incorrectly.
Also, the source-span assigned to an i18n message did not include leading
whitespace. This confused the output source-mappings so that the first text
nodes of the message stopped at the first non-whitespace character.
This commit makes use of the previous refactorings, where more fine grain
information was provided in text tokens, to enable the parser to identify
the location of the interpolations in the original source more accurately.
Fixes#41034
PR Close#43132
The tests were checking that the source-span of parsed HTML nodes were
accurate, but they were not checking the span when it includes the
"leading trivia", which are given by the `fullStart` rather than `start`
location.
PR Close#43132
When it was tokenized, text content is split into parts that can include
interpolations and encoded entities tokens.
To make this information available to downstream processing, this commit
adds these tokens to the `Text` AST nodes, with suitable processing.
PR Close#43132
The lexer now splits encoded entity tokens out from text and attribute value tokens.
Previously encoded entities would be decoded and the decoded value would be
included as part of the text token of the surrounding text. Now the entities
have their own tokens. There are two scenarios: text and attribute values.
Previously the contents of `<div>Hello & goodbye</div>` would be a single
TEXT token. Now it will be three tokens:
```
TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
TEXT: " goodbye"
```
Previously the attribute value in `<div title="Hello & goodbye">` would be
a single text token. Now it will be three tokens:
```
ATTR_VALUE_TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
ATTR_VALUE_TEXT: " goodbye"
```
- ENCODED_ENTITY tokens have two parts: "decoded" and "encoded".
- ENCODED_ENTITY tokens are always preceded and followed by either TEXT tokens
or ATTR_VALUE_TEXT tokens, depending upon the context, even if they represent
an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#43132
The lexer now splits interpolation tokens out from text tokens.
Previously the contents of `<div>Hello, {{ name}}<div>` would be a single
text token. Now it will be three tokens:
```
TEXT: "Hello, "
INTERPOLATION: "{{", " name", "}}"
TEXT: ""
```
- INTERPOLATION tokens have three parts, "start marker", "expression"
and "end marker".
- INTERPOLATION tokens are always preceded and followed by TEXT tokens,
even if they represent an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#43132
Previously, the regular expression used by the compiler's ShadowDOM CSS
shim to strip comments from CSS text was susceptible to [catastrophic
backtracking][1], which could lead to exponential (O(2^n)) increase in
complexity/execution time. More specifically, this would be triggered if
the processed text contained an unterminated comment with lots of
leading whitespace (i.e. `/*`, followed by lots of whitespace characters
and no closing `*/`).
Although such input is unlikely in real-world scenarios, this commit
improves the regular expression to not be susceptible to this issue.
[1]: https://www.regular-expressions.info/catastrophic.html
PR Close#43456
Previously the `http` example did accessed the npmsearch.com website to demonstrate response caching.
But if this service became unavailable then the example (and its e2e tests) would fail.
This commit changes the example to use the in-memory-web-api for this lookup, which will not be affected by 3rd party outages.
The guide that references this example has been updated to avoid references to the original npm search service.
PR Close#43475
Note that because `angular.json` is a "boilerplate" file we cannot
just add comments to the one that is actually used in the application.
Instead this commit makes a copy, which is annotated with docregions.
To ensure that this file is not ignored by the example-collector, we had to
update the `.gitignore` to not ignore this file. (This also allows the file to be
easily stored tracked in git).
PR Close#43216
It is now possible to specify file paths in the `"boilerplate-override"`
property of `example-config.json` files to tell the example boilerplate
system to use the file in the example directory rather than overwriting the
example file with that from the boilerplate directory.
PR Close#43216
This change makes docplaster markers fit better with the surrounding code
that is being rendered. Instead of:
```
{
"a": 100,
// ...
"b": 200,
// ...
}
```
you can now get
```
{
"a": 100,
// ...
"b": 200,
// ...
}
```
PR Close#43216
Now JSON files should be commented using
```
// #docregion
```
rather than
```
/* #docregion */
```
There are currently no JSON files with either kind of comments so this change
has no impact yet.
But when we add some examples with such comments, they will also benefit
from `// ... ` style docplasters to join docregion fragments.
PR Close#43216
No test was added for this case because I can't think of a test case to
write that would work.
This change updates the code for a consistent mental model of setting
the `browserUrlTree`. It's only meant to track the `UrlTree` that the
`UrlHandlingStrategy` is set to extract, not the full `rawUrl`. Notice
that everywhere else, the `browserUrlTree` is set to
`urlAfterRedirects`, which is computed based on the extracted URL, _not_
the `rawUrl`.
PR Close#43426
The HTML for the docs pages is generated by Dgeni based on some
[Nunjucks][1] templates.
Previously, these templates were set up in a way that introduced a lot
excess whitespace in the generated HTML, unnecessarily bloating the
corresponding JSON files that need to be downloaded in order to view a
certain docs page. This has been discussed in #28105 and was again
observed while investigating #43285.
This commit refactors some of the templates related to API docs (which
seem to be the most affected ones) to drastically reduce the amount of
excess whitespace. More specifically, the total size of all files in
`generated/docs/api/` was reduced from ~13MB to ~7MB.
Besides the reduced payload size for each API page, this change will
also reduce the amount of memory needed by the ServiceWorker to cache
the API pages that have been visited by a user.
NOTE:
The affected files are not eagerly downloaded when navigating to
angular.io. Instead, each file is downloaded individually, as soon as a
user visits the corresponding API docs page. Therefore, the impact of
this change will be relatively small for most users.
[1]: https://mozilla.github.io/nunjucks/
PR Close#43435
There are situations where the Router does not currently clean up failed navigations
correctly. While this is problematic on its own, we can mitigate some of
the damage by processing any URL when we get a navigation request when
the internal router state is out of sync.
Each of the added tests would fail without this change.
fixes#34795
PR Close#43424
tsec is a TypeScript compiler wrapper for restricting use of
security-sensitive DOM APIs, in particular those that could lead to XSS
or Trusted Types violations. Add it as a linter to aio to prevent future
Trusted Types regressions on angular.io.
Also introduces security_exemptions.json, which lists the known,
security-reviewed tsec security violations. New entries can only be
added to this file after a security review, in particular making sure
that the corresponding code does not cause XSS vulnerabilities or
Trusted Types violations.
PR Close#43406