The static interpreter assumed that a foreign function expression would
have to be imported from the absolute module specifier that was used for
the foreign function itself. This assumption does not hold for the
`forwardRef` foreign function resolver, as that extracts the resolved
expression from the function's argument, which is not behind the
absolute module import of the `forwardRef` function.
The prior behavior has worked for the typical usage of `forwardRef`,
when it is contained within the same source file as where the static
evaluation started. In that case, the resulting reference would
incorrectly have an absolute module guess of `@angular/core`, but the
local identifier emit strategy was capable of emitting the reference
without generating an import using the absolute module guess.
In the scenario where the static interpreter would first have to follow
a reference to a different source that contained the `forwardRef` would
the compilation fail. In that case, there is no local identifier
available such that the absolute module emitter would try to locate the
imported symbol from `@angular/core`. which fails as the symbol is not
exported from there.
This commit fixes the issue by checking whether a foreign expression
occurs in the same source file as the call expression. If it does, then
the absolute module specifier that was used to resolve the call
expression is ignored.
Fixes#42865
PR Close#42887
migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and
its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not
been removed (to be done in a next PR)
some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour
most TSLint rules have been substituted with their ESLint equivalent, with some exceptions:
* [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier)
* [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier)
* [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent
some rules have minor different behaviours compared to their TSLint counterparts:
* @typescript-eslint/naming-convention:
- typescript-eslint does not enforce uppercase for const only.
* @typescript-eslint/no-unused-expressions:
- The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored.
* arrow-body-style:
- ESLint will throw an error if the function body is multiline yet has a one-line return on it.
* eqeqeq:
- Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons.
* no-console:
- Custom console methods, if they exist, will no longer be allowed.
* no-invalid-this:
- Functions in methods will no longer be ignored.
* no-underscore-dangle:
- Leading and trailing underscores (_) on identifiers will now be ignored.
* prefer-arrow/prefer-arrow-functions:
- ESLint does not support allowing standalone function declarations.
- ESLint does not support allowing named functions defined with the function keyword.
* space-before-function-paren:
- Option "constructor" is not supported by ESLint.
- Option "method" is not supported by ESLint.
additional notes:
* the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported
versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should
likely/hopefully disappear in the future as typescript-eslint catches up
* The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console"
rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do
want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being
to simply only allow the "log", "warn" and "error" methods
* 4 dependencies have been added as they have been considered necessary (see: https://github.com/angular/angular/pull/42820#discussion_r669978232)
extra:
* the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin
* more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint
PR Close#42820
Use the version value from the primary package.json file rather than
checking the branch for the latest semver tag. This allows for us
to explictly create changelogs from the previous version to the new
version.
PR Close#42872
The angular-cli repo publishes experimental versioned packages in addition to standard
versioned packages. Both experimental and standard verions, based on the expected new
version provided are treated as valid and correct.
PR Close#42898
improve the @usageNotes message by adding the word "is"
(outcome: "Further information is available in...", compared to
"Further information available in...")
PR Close#42888
When a directive provides a DI token using a factory function and
interacting with a standalone injector from within that factory, the
standalone injector should not have access to either the directive
injector nor the NgModule injector; only the standalone injector should
be used.
This commit ensures that a standalone injector never reaches into the
directive-level injection context while resolving DI tokens.
Fixes#42651
PR Close#42886
Previously, if there was more content than what would horizontally fit
in the main content area, it would overflow to the right and overlap
with the Table of Contents (ToC).
This was accidentally introduced in #42787.
This commit fixes it by ensuring that the main content area will not
overlap with ToC and the necessary space for the ToC will be reserved
using `margin` (instead of `padding`, which contributes to the element's
size).
Fixes#42867
PR Close#42884
Error-handling in AIO happens mainly in two places:
1. For errors happening inside the app we have a custom `ErrorHandler`
implementation, `ReportingErrorHandler`. `ReportingErrorHandler`
passes errors to the default `ErrorHandler` (for them to be logged to
the console) and also forwards them to `window.onerror()`.
2. Errors happening outside the app and errors forwarded by
`ReportingErrorHandler` are handled by `window.onerror()`, which in
turn reports them to Google analytics.
Previously, we were making some assumptions (which turned out to be
incorrect based on the info captured in Google analytics - see #28106):
- `ReportingErrorHandler` assumed that the errors passed to its
`handleError()` method would be either strings or `Error` instances.
_Apparently, other values (such as `null` or `undefined`) may also be
passed._
- `window.onerror()` assumed that if an `Error` instance was passed in,
it would always have a stacktrace (i.e. its `stack` property would be
defined).
_This is not necessarily true, although it is not clear (based on the
logs) whether reported errors of this type are caused by `Error`
instance with no stacktrace or by non-string error objects which are
incorrectly treated as `Error` instances.
This commit ensures that all types of error arguments can be handled
correctly, including `Error` instances with no stacktrace and other
types of objects or primitives.
NOTE:
PR #42881 is related as it fixes handling `null` and `undefined`
arguments in the default `ErrorHandler`.
Fixes#28106
PR Close#42883
Previously we disabled automatic type-resolution for the API
extractor because in non-sandbox environments this resulted in
different API reports. There are cases where global types are
still needed for analysis of an entry-point. To support this,
we add a new property called `types` which allows for explicit
type targets being specified.
Note that we do not want to determine types from the `data`
runfiles because API extractor itself also brings in types
which should not always be part of the API report analysis.
PR Close#42876
In the past when we had issues with our RBE instance, we wanted
to get CI green as soon as possible, and couldn't wait on the
components repo to land their RBE instance fix. We manually
fixed the RBE instance name using a CI step using `sed`.
This is no longer needed if we update to the most recent
state of the components repository.
PR Close#42875
We recently updated to Husky v7 through Renovate, but
as of Husky v7, a `.gitignore` file is no longer needed.
This commit removes the file.
PR Close#42870
Currently, changes with the `bazel` scope are guarded by the
merge tool target label checks. i.e. feature commits with
the `bazel` scope cannot land in the patch branch. This is
expected for all public packages, but given the `bazel`
package being used internal-only, it should be possible
to land these in a patch branch. Especially since we want
tooling to be in sync between version branches as much
as possible.
PR Close#42869
Previously the wombot proxy was not able to be queried for login state, now
that it is able to be checked via `npm whoami` a specific alternate flow
is no longer needed.
PR Close#42871
`waitForPullRequestToBeMerged` should get the entire `PullRequest` object rather than
just the id to allow it to have more information/context for logging and messaging.
PR Close#42871
the final styles created in buildStyles lack normalization, meaning that pixel values remain as numbers (without "px") and so such properties fail to be correctly set/applied
Example: "width: 300" is applies as "width": "300" (and thus ignored) instead of the correct "width": "300px"
PR Close#42763
fix the typo "mean't" in the transition_animation_engine spec file
to "meant" (the typo is simply in a code comment so the change
does not have any impact)
PR Close#42763
With the refactoring from a Gulp task to a Bazel too, we tried switching
away from the hard-coded list of locales and aliases for the Closure
Locale file generation. After multiple attempts of landing this, it
turned out that Closure Compiler/Closure Library relies on locale
identifiers CLDR does not capture within it's `availableLocales.json`
or `aliases.json` data.
Closure Library does not use any unknown locale identifiers here. The
locale identifiers can be resolved within CLDR using the bundle lookup
algorithm that is specified as part of CLDR; instead the problem is that
the locale identifiers do not follow any reasonable pattern and
therefore it's extremely difficult to generate them automatically (it's
almost like we'd need to build up _all_ possible combinations). Instead
of doing that, we just use the hard-coded locales and aliases from the
old Closure Locale generation script.
PR Close#42230
Within Google, closure compiler is used for dealing with translations.
We generate a closure-compatible locale file that allows for
registration within Angular, so that Closure i18n works well together
with Angular applications. Closure compiler does not limit its
locales to BCP47-canonical locale identifiers. This commit updates
the generation logic so that we also support deprecated (but aliased)
locale identifiers, or other aliases which are likely used within
Closure. We use CLDR's alias supplemental data for this. It instructs
us to alias `iw` to `he` for example. `iw` is still supported in Closure.
Note that we do not manually extract all locales supported in Closure;
instead we only support the CLDR canonical locales (as done before) +
common aliases that CLDR provides data for. We are not aware of other
locale aliases within Closure that wouldn't be part of the CLDR aliases.
If there would be, then Angular/Closure would fail accordingly.
PR Close#42230
In the past, the closure file has been generated so that all individual
locale files were imported individually. This resulted in a huge
slow-down in g3 due to the large amount of imports.
With 90bd984ff7 this changed so that we
inline the locale data for the g3 closure locale file. Also the file
only contained data for locales being supported by Closure. For this a
list of locales has been extracted from Closure Compiler, as well as a
list of locale aliases.
This logic is prone to CLDR version updates, and also broke as part of
the Gulp -> Bazel migration where this logic has been slightly modified
but caused issues in G3. e.g. a locale `zh-Hant` was requested in g3,
but the locale data had the name of the alias locale that provided the
data at index zero (which represents the locale name). Note that the
locale names at index zero always could differentiate from the requested
`goog.LOCALE` due to the aliasing logic. This just didn't come up before.
We simplify this logic by generating a `goog.LOCALE` case for all
locales CLDR provides data for. We don't need to bother about aliasing
because with the refactorings to the CLDR generation tool, all locales
are built (which also captures the aliases), and we can generate the locale
file on the fly (which has not been done before).
PR Close#42230
The CLDR extraction tool has been reworked to run as part of Bazel.
This adds a initial readme explaining what the tool generates. It's
far from a detailed description but it can serve as foundation for more
detailed explanations.
PR Close#42230
Given that the locale files are now generated through
Bazel, the files are no longer checked-in and the
legacy TSC compilation fails due to imports resolving
to non-existent files. We fix this for the legacy
saucelabs job by copying the generated TS files into
the sources (which is acceptable for the isolated CI job)
PR Close#42230
Introduces a few Starlark macros for running the new Bazel
CLDR generation tool. Wires up the new tool so that locales
are generated properly. Also updates the existing
`closure-locale` file to match the new output generated by the Bazel tool.
This commit also re-adds a few locale files that aren't
generated by CLDR 37, but have been accidentally left in
the repository as the Gulp script never removed old locales
from previous CLDR versions. This problem is solved with the
Bazel generation of locale files, but for now we re-add these
old CLDR 33 locale files to not break developers relying on these
(even though the locale data indicies are incorrect; but there might
be users accessing the data directly)
PR Close#42230
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
This is a pre-refactor commit allowing us to move
the CLDR locale generation to Bazel where files would
no longer be checked-in, except for the `closure-locale`
file that is synced into Google3.
PR Close#42230
This commit upgrades `lighthouse` to the latest version (8.1.0) to take
advantage of latest fixes/improvements and ensure the min scores are
still met with the latest audit changes.
PR Close#42846
If a decorator or partial declaration has not been AOT compiled, then
the compiler is needed at runtime to be able to JIT compile the code.
However, it may occur that the compiler is not available, if it has not
been loaded into the application. The error that was reported in this
case did not provide insight into which class requested compilation, nor
did it differentiate between decorators vs. partial declarations.
This commit expands the error logging to provide better insight into the
class that initiated JIT compilation and offers a specialized error
message for partial declarations. This should help a developer better
understand why the error occurs and what can be done to resolve it.
Closes#40609
PR Close#42693
For the compilation of a component, the compiler verifies that the
imports it needs to generate to reference the used directives and pipes
would not create an import cycle in the program. This requires visiting
the transitive import graphs of all directive/pipe usage in search of
the component file. The observation can be made that all directive/pipe
usages can leverage the exploration work in search of the component
file, thereby allowing sub-graphs of the import graph to be only visited
once instead of repeatedly per usage. Additionally, the transitive
imports of a file are no longer collected into a set to reduce memory
pressure.
PR Close#41271
Re-add reference to Trusted Types since the issue #41754 is resolved in 12.1.1.
This reverts commit 7254fbc2baa1455e3b24400597342843df3017f2.
PR Close#42796
When using `TestBed.overrideComponent`, the overridden component would
incorrectly lose access to its NgModule's declaration scope if the
NgModule had been imported into the testing NgModule as a
`ModuleWithProviders`, e.g. using a `forRoot` call.
The issue occurred as the `TestBed` compiler did not consider NgModules
that had been imported as a `ModuleWithProviders` when associating
NgModules with component overrides. This caused the overridden component
to be compiled standalone, meaning that it does not have access to
its NgModule's declarations. This commit extends the logic for
traversing the NgModule graph to also consider `ModuleWithProviders`
imports.
Fixes#42734
PR Close#42817
In #41995 the type of `TrackByFunction` was changed such that the
declaration of a `trackBy` function did not cause the item type to be
widened to the `trackBy`'s item type, which may be a supertype of the
iterated type. This has introduced situations where the template type
checker is now reporting errors for cases where a `trackBy` function is
no longer assignable to `TrackByFunction`.
This commit fixes the error by also including the item type `T` in
addition to the constrained type parameter `U`, allowing TypeScript to
infer an appropriate `T`.
Fixes#42609
PR Close#42692
Previously, if only the `compareFn` changed but the data itself did not, then
the `KeyValuePipe` did not re-sort the output.
Fixes#42819
PR Close#42821
JoostK
dario-piotrowicz
Joey Perrott
George Kalpakas
Paul Gschwendtner
Renovate Bot
Minko Gechev
David Shevitz
Krzysztof Kotowicz
Alan Agius
Andrew Kushnir
Meir Blumenfeld