It seems that at some point (potentially with the switch to Webpack 5)
Webpack started using the full chunk name (instead of just a numeric
identifier) in `ChunkLoadError` messages. So the error messages changed
from:
```
ChunkLoadError: Loading chunk 2 failed.
```
...to:
```
ChunkLoadError: Loading chunk src_app_something_some_module_ts failed.
```
This commit updates the regex that is used to detect such errors (in
order to print ServiceWorker-related debug info) to correctly recognize
the new error message format.
PR Close#43088
This commit updates the docs examples to Angular v12.1.3. In addition to
updating the dependencies versions, it also updates the projects'
structure and configs to more closely match what a new v12 CLI app would
look like. See, also, the [diff][1] between a basic v11.2.11 CLI app and
a v12.1.3 one.
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/11.2.11..12.1.3
PR Close#42949
According to the URI spec, question mark characters are valid in query data,
so these should accepted by the param parsing.
See https://tools.ietf.org/html/rfc3986#section-3.4Fixes#31116
BREAKING CHANGE: The default url serializer would previously drop
everything after and including a question mark in query parameters. That
is, for a navigation to `/path?q=hello?&other=123`, the query
params would be parsed to just `{q: 'hello'}`. This is
incorrect because the URI spec allows for question mark characers in
query data. This change will now correctly parse the params for the
above example to be `{v: 'hello?', other: '123'}`.
PR Close#31187
Specifically: narrow the type used for form statuses from string to a union of possible statuses. Change the API methods from any to use the new type.
This is a breaking change. However, as discussed in the PR, breakage seems minimal, and google3 has been prepped to land this.
Background: we uncovered these any typings in the course of design work for typed forms. They could be fixed in a non-breaking manner by piggybacking them on top of the new typed forms generics, but it would be much cleaner to fix them separately if possible.
BREAKING CHANGE:
A new type called `FormControlStatus` has been introduced, which is a union of all possible status strings for form controls. `AbstractControl.status` has been narrowed from `string` to `FormControlStatus`, and `statusChanges` has been narrowed from `Observable<any>` to `Observable<FormControlStatus>`. Most applications should consume the new types seamlessly. Any breakage caused by this change is likely due to one of the following two problems: (1) the app is comparing `AbstractControl.status` against a string which is not a valid status; or, (2) the app is using `statusChanges` events as if they were something other than strings.
PR Close#42952
Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views.
The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`).
These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation.
Fixes#41383.
PR Close#43005
When the user tries to trigger suggestions from an interruption,
the LS should provide the global completions. For example,
`[input]="t¦"`, the `t` can be the `true` or the symbol from
the component context.
PR Close#42923
We can't update the framework to rxjs7 until version 13, because it contains breaking changes, but we can allow users to opt into it since all of our code should be compatible.
These changes expand the allowed version range of rxjs and add an integration test to verify that we don't get compilation errors. Note that we also have a test that runs the AIO examples against rxjs 7 already (#42660).
Fixes#41897.
PR Close#42991
This commit renames shims_for_IE.js -> shims_for_internal_tests.js, since there are no IE shims there anymore (there are still shims for older Safari and Android versions).
PR Close#43002
This commit performs several updates to stop running tests in IE11 on CI (since IE11 support was deprecated in v12 and will be dropped in v13).
PR Close#43002
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#42062
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#42062
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#42062
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#42062
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#42062
The lexer now splits interpolation tokens out from attribute value tokens.
Previously the attribute value of `<div attr="Hello, {{ name}}">` would be a single
token. Now it will be three tokens:
```
ATTR_VALUE_TEXT: "Hello, "
ATTR_VALUE_INTERPOLATION: "{{", " name", "}}"
ATTR_VALUE_TEXT: ""
```
- ATTR_VALUE_INTERPOLATION tokens have three parts, "start marker",
"expression" and "end marker".
- ATTR_VALUE_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#42062
This function is general purpose and by moving it into the
`chars.ts` file along with similar helpers, it can be reused
in the lexer, for instance.
PR Close#42062
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#42062
The compliance tests can check source-map segments against expectations
encoded into the expectation files. Previously, the encoding of the expected
segment was only delimited by whitespace, but this made it difficult to identify
segments that started or ended with whitespace.
Now these segment expectations are wrapped in double-quotes which makes
it easier to read and understand the expectation files.
PR Close#42062
George Kalpakas
Andrew Scott
Jeroen van Warmerdam
Jon Rimmer
Joey Perrott
Fabien BERNARD
Dylan Hunn
Andrew Scott
Kristiyan Kostadinov
ivanwonder
dario-piotrowicz
Andrew Kushnir
Pete Bacon Darwin