This commit fixes a confusing description of the `strictTemplates` flag.
> When `true`, enables strict template type checking in Angular version 9.
This seems to imply that the flag is only available in one version.
Strict template type checking is available in version 9 **and above**.
PR Close#39745
This commit downgrades `karma` to version 5.1.1, because of a regression
in version 5.2.0: karma-runner/karma#3560
It has been fixed with karma-runner/karma@05dc288016 on
master, but the fix is not included in the latest release (v5.2.3).
PR Close#39600
This commit updates `@angular/*` and `@angular/cli` (and related
packages) to version 11.0.0-rc.2. Apart from the automatic migrations,
this commit also tries to align `aio/` with new apps generated by the
latest CLI. (See [here][1] for a diff between a v10.1.3 and a
v11.0.0-rc.2 CLI app.)
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/10.1.3...11.0.0-rc.2
PR Close#39600
Allowing command line arguments to provide the file and source values to
the restore-commit-message command will assist in the the process of
upgrading to husky@5.
PR Close#39739
language_service_adapter_spec was renamed to adapters_spec as part of
d39c4bbe37, but I failed to check in
adapters_spec, thereby just deleting the spec. This reintroduces it.
PR Close#39742
This commit makes the breaking changes section of the v11.0.0 release
info in `CHANGELOG.md` easier to follow by:
1. Adding links to the corresponding commit for each breaking change (to
make it easier to find the full context of the change).
2. Turning breaking changes of each scope into a bulleted list (to make
it clearer that they affect the same package/scope).
NOTE:
It would be better if the changelog generation tooling handled this
automatically. This potential improvement is being tracked in #39698.
PR Close#39704
Usually, entries in the release notes for a version in `CHANGELOG.md` are
grouped by scope (i.e. all `compiler` changes together, all `router`
changes together, etc.). Currently, the notes for a non-patch release
are created manually, by contatenating the release notes for all
corresponding next/RC versions. As a result, the entries for v11.0.0 are
not grouped together.
This commit fixes it by grouping all entries for the v11.0.0 release by
scope, making it easier to identify all changes that affect a specific
package/scope.
PR Close#39704
It seems that the script used to generate the `CHANGELOG.md` content
incorrectly treats any link or issue/PR reference in the commit message
as a link to an issue fixed/closed by the commit. However, there are
cases where such links/references do not refer to issues fixed/closed by
the commit (or not refer to issues at all).
This commit fixes such bogus links in the v11.0.0 release info.
NOTE:
The underlying issue should be more generically addressed in the
changelog generation tooling. This is being tracked in #39698.
PR Close#39704
Currently, the script that is used to generate the `CHANGELOG.md`
content uses the first 7 characters of a commit SHA in the generated
links. This is problematic when there are multiple commits in the repo
(or forks of the repo?) that start with the same 7 characters (which is
rare but possible), since GitHub shows a 404 page.
This was the case with commit 736e0644b02bc4606a7ae0c974d1b06e993708f6
that is included in the v11.0.0 release notes and happens to start with
the same characters as commit 736e064ac80f5e0ed84711694c2ba68809222ffd.
This commit fixes the issue by using the full commit SHA in the link for
this particular commit.
NOTE:
The underlying issue should be more generically addressed in the
changelog generation tooling. This is being tracked in #39698.
PR Close#39704
Commit 4ca1c736bb (part of PR #38931) was
incorrectly marked with scope `packaging`, while it is an internal-only
change (i.e. it does not affect packaging). As such is should have been
marked with a different scope (for example, `ci`/`build`/`refactoring`)
and should not appear in `CHANGELOG.md`.
This commit removes the entry from `CHANGELOG.md` to avoid confusing
developers trying to understand how this change may affect their apps.
NOTE:
The commit contains a breaking change notice (about dropping support for
IE<11) which _is_ relevant to app developers. This breaking change
notice is preserved in the "BREAKING CHANGES" section, but the scope is
changes from `packaging` to `core` to avoid confusion.
PR Close#39704
This commit includes several minor fixes in the v11.0.0 release info in
`CHANGELOG.md`, such as:
- Fixing typos/punctuation.
- Making capitalization consistent.
- Wrapping code in backticks (for better readability).
PR Close#39704
Previously we hand coded the list of previous major versions
that are displayed in the left navigation.
Now these are generated from the tags in GitHub.
Closes#39688
PR Close#39689
The `HttpParamsOptions` was not documented or included in the public API even
though it is a constructor argument of `HttpParams` which is a part of the
public API. This commit adds the `HttpParamsOptions` into the exports, thus
making it a part of the public API.
Resolves#20276
PR Close#35829
Currently `readConfiguration` relies on the file system to perform disk
utilities needed to read determine a project configuration file and read
it. This poses a challenge for the language service, which would like to
use `readConfiguration` to watch and read configurations dependent on
extended tsconfigs (#39134). Challenges are at least twofold:
1. To test this, the langauge service would need to provide to the
compiler a mock file system.
2. The language service uses file system utilities primarily through
TypeScript's `Project` abstraction. In general this should correspond
to the underlying file system, but it may differ and it is better to
go through one channel when possible.
This patch alleviates the concern by directly providing to the compiler
a "ParseConfigurationHost" with read-only "file system"-like utilties.
For the language service, this host is derived from the project owned by
the language service.
For more discussion see
https://docs.google.com/document/d/1TrbT-m7bqyYZICmZYHjnJ7NG9Vzt5Rd967h43Qx8jw0/edit?usp=sharing
PR Close#39619
Before this change, when trying to load a JSONP script that calls the JSONP callback inside a
microtask, it will fail in Internet Explorer 11 and EdgeHTML. This commit changes the onLoad cleanup
to be queued after the loaded endpoint executed any potential microtask itself. This ensures that
the aforementioned browsers will first evaluate the loaded script calling the JSONP callback and
only then run the cleanup inside onLoad.
Fixes#39496
PR Close#39512
This commit adds new language service testing infrastructure which allows
for in-memory testing. It solves a number of issues with the previous
testing infrastructure that relied on a single integration project across
all of the tests, and also provides for much faster builds by using
the compiler-cli's mock versions of @angular/core and @angular/common.
A new `LanguageServiceTestEnvironment` class (conceptually mirroring the
compiler-cli `NgtscTestEnvironment`) controls setup and execution of tests.
The `FileSystem` abstraction is used to drive a `ts.server.ServerHost`,
which backs the language service infrastructure.
Since many language service tests revolve around the template, the API is
currently optimized to spin up a "skeleton" project and then override its
template for each test.
The existing Quick Info tests (quick_info_spec.ts) were ported to the new
infrastructure for validation. The tests were cleaned up a bit to remove
unnecessary initializations as well as correct legitimate template errors
which did not affect the test outcome, but caused additional validation of
test correctness to fail. They still utilize a shared project with all
fields required for each individual unit test, which is an anti-pattern, but
new tests can now easily be written independently without relying on the
shared project, which was extremely difficult previously. Future cleanup
work might refactor these tests to be more independent.
PR Close#39594
In preparation for in-memory testing infrastructure, the existing Ivy
language service tests are moved to a `legacy` directory. These existing
tests rely on a single integration project in `test/project/app`, which
presents a number of challenges:
* adding extra fields/properties to the integration project for one test
can cause others to fail/flake.
* it's especially difficult to test any cases that require introducing
intentional errors, as those tend to break other tests.
* tests load files from disk, which is slower.
* tests rely on the real built versions of @angular/core and
@angular/common, which makes them both slow to build and require rebuilds
on every compiler change.
* tests share a single tsconfig.json, making it extremely difficult to test
how the language service handles different configuration scenarios (e.g.
different type-checking flags).
PR Close#39594
ngtsc's testing infrastructure uses a mock version of @angular/core, which
allows tests to run without requiring the real version of core to be built.
This commit adds a mock version of @angular/common as well, as the language
service tests are written to test against common.
Only a handful of directives/pipes from common are currently supported.
PR Close#39594
ngtsc has a robust suite of testing utilities, designed for in-memory
testing of a TypeScript compiler. Previously these utilities lived in the
`test` directory for the compiler-cli package.
This commit moves those utilities to an `ngtsc/testing` package, enabling
them to be depended on separately and opening the door for using them from
the upcoming language server testing infrastructure.
As part of this refactoring, the `fake_core` package (a lightweight API
replacement for @angular/core) is expanded to include functionality needed
for Language Service test use cases.
PR Close#39594
ngNonBindable documentation was not present, on docs site added documentation for ngNonBindable. With this template primitive, Angular won't
evaluate expressions in elements.
Fixes#28577Fixes#19497
PR Close#36560
The result of utf-8 encoding a string was represented in a string, where
each individual character represented a single byte according to its
character code. All usages of this data were interested in the byte
itself, so this required conversion from a character back to its code.
This commit simply stores the individual bytes in array to avoid the
conversion. This yields a ~10% performance improvement for i18n message
ID computation.
PR Close#39694
Message ID computation makes extensive use of big integer
multiplications in order to translate the message's fingerprint into
a numerical representation. In large compilations with heavy use of i18n
this was showing up high in profiler sessions.
There are two factors contributing to the bottleneck:
1. a suboptimal big integer representation using strings, which requires
repeated allocation and conversion from a character to numeric digits
and back.
2. repeated computation of the necessary base-256 exponents and their
multiplication factors.
The first bottleneck is addressed using a representation that uses an
array of individual digits. This avoids repeated conversion and
allocation overhead is also greatly reduced, as adding two big integers
can now be done in-place with virtually no memory allocations.
The second point is addressed by a memoized exponentiation pool to
optimize the multiplication of a base-256 exponent.
As an additional optimization are the two 32-bit words now converted to
decimal per word, instead of going through an intermediate byte buffer
and doing the decimal conversion per byte.
The results of these optimizations depend a lot on the number of i18n
messages for which a message should be computed. Benchmarks have shown
that computing message IDs is now ~6x faster for 1,000 messages, ~14x
faster for 10,000 messages, and ~24x faster for 100,000 messages.
PR Close#39694
Currently when we encounter an implicit method call (e.g. `{{ foo(1) }}`) and we manage to resolve
its receiver to something within the template, we assume that the method is on the receiver itself
so we generate a type checking code to reflect it. This assumption is true in most cases, but it
breaks down if the call is on an implicit receiver and the receiver itself is being invoked. E.g.
```
<div *ngFor="let fn of functions">{{ fn(1) }}</div>
```
These changes resolve the issue by generating a regular function call if the method call's receiver
is pointing to `$implicit`.
Fixes#39634.
PR Close#39686
In order to more accurately map from a node in the TCB to a template position,
we need to provide more span information in the TCB. These changes are necessary
for the Language Service to map from a TCB node back to a specific
locations in the template for actions like "find references" and
"refactor/rename". After the TS "find references" returns results,
including those in the TCB, we need to map specifically to the matching
key/value spans in the template rather than the entire source span.
This also has the benefit of producing diagnostics which align more
closely with what TypeScript produces.
The following example shows TS code and the diagnostic produced by an invalid assignment to a property:
```
let a: {age: number} = {} as any;
a.age = 'laksjdf';
^^^^^ <-- Type 'string' is not assignable to type 'number'.
```
A corollary to this in a template file would be [age]="'someString'". The diagnostic we currently produce for this is:
```
Type 'number' is not assignable to type 'string'.
1 <app-hello [greeting]="1"></app-hello>
~~~~~~~~~~~~~~
```
Notice that the underlined text includes the entire span.
If we included the keySpan for the assignment to the property,
this diagnostic underline would be more similar to the one produced by TypeScript;
that is, it would only underline “greeting”.
[design/discussion doc]
(https://docs.google.com/document/d/1FtaHdVL805wKe4E6FxVTnVHl38lICoHIjS2nThtRJ6I/edit?usp=sharing)
PR Close#39665
This commit removes the TODO comment that proposed
that we use the built-in RxJS `isObservable()` function.
This is not a viable approach since the built-in function
requires that the `obj` contains additional methods that
our "observable" types (such as `EventEmitter`) do not
necessarily have.
See #39643 for more information.
PR Close#39669
`ViewRef` and `ApplicationRef` had a circular reference. This change
introduces `ViewRefTracker` which is a subset of `ApplicationRef` for
this purpose.
PR Close#39621
JIT needs to identify which type is `ChangeDetectorRef`. It was doing so
by importing `ChangeDetectorRef` and than comparing the types. This creates
circular dependency as well as prevents tree shaking. The new solution is
to brand the class with `__ChangeDetectorRef__` so that it can be identified
without creating circular dependency.
PR Close#39621
`LContainer` stores `ViewRef`s this is not quite right as it creates
circular dependency between the two types. Also `LContainer` should not
be aware of `ViewRef` which iv ViewEngine specific construct.
PR Close#39621
Keen Yee Liau
David Shevitz
George Kalpakas
Licanueto
Joey Perrott
ayazhafiz
atscott
Misko Hevery
Egor
Pete Bacon Darwin
ngdevelop-tech
Ray Logel
Santosh Yadav
spixy
Antonio Cardenas
Sebastian Häni
Alex Rickabaugh
Ajit Singh
JoostK
Andrew Scott
Kristiyan Kostadinov