- @angular dependencies point to ../../dist
- use absolute versions for other dependencies
- add a yarn.lock
- create ci-specific targets
- make karma and protractor use correct Chrome binary
PR Close#39614
Create an integration test for testing support for Trusted Types in Ivy.
Generated with:
```
yarn ng new ivy-trusted-types -g --skip-install --style css --routing --strict
```
PR Close#39614
Consumers of the `TemplateTypeChecker` API could be interested in
mapping from a shim location back to the original source location in the
template. One concrete example of this use-case is for the "find
references" action in the Language Service. This will return locations
in the TypeScript shim file, and we will then need to be able to map the
result back to the template.
PR Close#39715
Both `ReferenceSymbol` and `VariableSymbol` have two locations of
interest to an external consumer.
1. The location for the initializers of the local TCB variables allow consumers
to query the TypeScript Language Service for information about the initialized type of the variable.
2. The location of the local variable itself (i.e. `_t1`) allows
consumers to query the TypeScript LS for references to that variable
from within the template.
PR Close#39715
The codebase currently contains several `noop` functions,
and they can end up in the bundle of an application.
A recent commit 6fbe21941d tipped us off
as it introduced several `noop` occurrences in the golden symbol files.
After investigating with @petebacondarwin,
we decided to remove the duplicated functions.
This probably shaves only a few bytes,
but this commit removes the duplicated functions,
by always using the one in `core/src/utils/noop`.
PR Close#39761
Occasionally, the SW would end up in a broken state where some of the
eagerly cached resources of an older version were available in the local
cache, but others (such as lazy-loaded bundles) were not. This would
leave the app in a broken state and a blank screen would be displayed.
See #28114 for a more detailed discussion.
This commit takes advantage of the newly introduced (in v11)
[SwUpdate#unrecoverable][1] API to detect these bad states and recover
by doing a full page reload whenever an [UnrecoverableStateEvent][2] is
emitted.
Partially addresses #28114.
NOTE:
Currently, `SwUpdate.unrecoverable` only works if the app has already
bootstrapped; i.e. if only lazy-loaded bundles have been purged from the
cache.
That should be fine in practice, since the cache entries are removed in
least-recently-used order. Thus the eagerly loaded bundles will be the
last to be removed from the cache (which rarely happens in practice).
[1]: https://v11.angular.io/api/service-worker/SwUpdate#unrecoverable
[2]: https://v11.angular.io/api/service-worker/UnrecoverableStateEvent
PR Close#39651
Previously, the `LocationService` depended on the `SwUpdatesService`.
This felt backwards, since `LocationService` is a more low-level and
basic service and should not be depending on a service for a
higher-level, specific feature (ServiceWorkers).
This commit inverses the relation, making `SwUpdatesService` depend on
`LocationService` instead.
PR Close#39651
Since we have a `MockLogger` class in `src/testing/`, there is no need
to create a new `MockLogger` class for the `SwUpdatesService` unit
tests.
This commit switches to using the `MockLogger` class from
`src/testing/`.
PR Close#39651
In #38762 we added a migration to replace the deprecated `preserveQueryParams`
option with `queryParamsHandling`, however due to a typo, we ended up replacing it
with `queryParamsHandler` which is invalid.
Fixes#39755.
PR Close#39763
Removes duplicate info, moves document into conceptual
reference section, but doesn't edit remaining content.
Groups two dependency injection documents together in
one expandable nav section.
PR Close#39544
There is a typo in zone.js bundle format breaking change part,
the correct version should be `0.11.1` not `0.11.11`, and add
more clear text to explain the new bundle format directory structure.
PR Close#39508
The 15.x versions of `yargs` relied upon a version of `y18n` that
has a SNYK vulnerability.
This commit updates the overall project, and therefore also the
`localize` and `compiler-cli` packages to use the latest version
of `yargs` that does not depend upon the vulnerable `y18n`
version.
The AIO project was already on the latest `yargs` version and so
does not need upgrading.
Fixes#39743
PR Close#39749
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
Bjarki
Andrew Scott
cexbrayat
George Kalpakas
Andrew Kushnir
Kristiyan Kostadinov
Kapunahele Wong
JiaLiPassion
Pete Bacon Darwin
Keen Yee Liau
David Shevitz
Licanueto
Joey Perrott
ayazhafiz
atscott
Misko Hevery
Egor
ngdevelop-tech
Ray Logel
Santosh Yadav
spixy
Antonio Cardenas
Sebastian Häni
Alex Rickabaugh