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
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
Before this commit, attribute completion display parts were retrieved
but not assigned. In addition, the switch case was non-exhaustive
because it did not include `StructuralDirectiveAttribute`.
PR Close#42472
In the past, when we enabled `--strict` in the repository, we added
another tsconfig for code not being migrated to be `--strict`
compatible. This was done for the deprecated http and webworker
packages. Since these are now removed, we can rmeove the logic.
PR Close#42506
The `NO_ERRORS_SCHEMA` schema can be used to ignore errors related to unknown elements or properties, but since it suppresses these errors it may also hide real problems in a template. This commit updates the `NO_ERRORS_SCHEMA` docs to mention that.
Closes#39454.
PR Close#42327
This is based on a discussion we had a few weeks ago. Currently if a component uses `ViewEncapsulation.ShadowDom` and its selector doesn't meet the requirements for a custom element tag name, a vague error will be thrown at runtime saying something like "Element does not support attachShadowRoot".
These changes add a new diagnostic to the compiler that validates the component selector and gives a better error message during compilation.
PR Close#42245
For quite a while it is an unspoken convention to add a trailing
new-line files within the Angular repository. This was never enforced
automatically, but has been frequently raised in pull requests through
manual review. This commit sets up a lint rule so that this is
"officially" enforced and doesn't require manual review.
PR Close#42478
Updates the compiler-cli compliance goldens. The golden updates are
required due to a regression in TypeScript 4.3 that causes the emitter
to not incorrectly preserve lines when emitting a node list.
This can be reverted once https://github.com/microsoft/TypeScript/pull/44070
is available.
PR Close#42022
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
Currently we support safe property (`a?.b`) and method (`a?.b()`) accesses, but we don't handle safe keyed reads (`a?.[0]`) which is inconsistent. These changes expand the compiler in order to support safe key read expressions as well.
PR Close#41911
As previously discussed in pull/31070 and issues/30486, this would be useful because it is often desirable to apply styles to fields that are both `ng-invalid` and `ng-pristine` after the first attempt at form submission, but Angular does not provide any simple way to do this (although evidently Angularjs did). This will now be possible with a descendant selector such as `.ng-submitted .ng-invalid`.
In this implementation, the directive that sets control status classes on forms and formGroups has its set of statuses widened to include `ng-submitted`. Then, in the event that `is('submitted')` is invoked, the `submitted` property of the control container is returned iff it exists. This is preferred over checking whether the container is a `Form` or `FormGroup` directly to avoid reflecting on those classes.
Closes#30486.
PR Close#42132
With the removal of the `ModuleWithProviders` transform in the parent commit,
the underlying dts transform can also be removed as it is not used elsewhere.
PR Close#41996
The `ModuleWithProviders` type has required a generic type since Angular 10,
so it is no longer necessary for the compiler to transform usages of the
`ModuleWithProviders` type without the generic type, as that should have
been reported as a compile error. This commit removes the detection logic
from ngtsc.
PR Close#41996
Prior to this change the `min` and `max` validator directives would not
set the `min` and `max` attributes on the host element. The problem was
caused by the truthy check in host binding expression that was
calculated as `false` when `0` is used as a value. This commit updates
the logic to leverage nullish coalescing operator in these host binding
expressions, so `0` is treated as a valid value, thus the `min` and
`max` attributes are set correctly.
Partially closes#42267
PR Close#42412
When a `trackBy` function is used that accepts a supertype of the iterated
array's type, the loop variable would undesirably be inferred as the supertype
instead of the array's item type. This commit adds an inferred type parameter
to `TrackByFunction` to allow an extra degree of freedom, enabling the
loop value to be inferred as the most narrow type.
Fixes#40125
PR Close#41995
The ngtsc test targets have fake declarations files for `@angular/core`
and `@angular/common` and the template type checking tests can leverage
the fake common declarations instead of declaring its own types.
PR Close#41995
Type-only imports are known to be elided by TypeScript, so the compiler
can be certain that such imports do not contribute to potential import
cycles. As such, type-only imports are no longer considered during cycle
analysis.
Regular import statements that would eventually be fully elided by
TypeScript during emit if none of the imported symbols are used in a
value position continue to be included in the cycle analysis, as the
cycle analyzer is unaware of these elision opportunities. Only explicit
`import type` statements are excluded.
PR Close#42453
This change moves the `dev-infra/browsers` folder into `dev-infra/bazel`.
The browser folder is providing custom configuration for Bazel, so it
should live within the `bazel` folder for a more well-structured
`dev-infra` folder.
PR Close#42268
Prior to this PR, attempting to get rename info for pipe name expressions would defer to the
typescript language service, which would return no rename info. This was not caught because
the test was written incorrectly.
This PR corrects the test behavior and adjusts the logic in getting rename info to account
for indirect renames (like pipe names).
PR Close#41974
The compiler flag `compileNonExportedClasses` allows the Angular compiler to
process classes which are not exported at the top level of a source file.
This is often used to allow for AOT compilation of test classes inside
`it()` test blocks, for example.
Previously, the compiler would identify exported classes by looking for an
`export` modifier on the class declaration itself. This works for the
trivial case, but fails for indirectly exported classes:
```typescript
// Component is declared unexported.
@Component({...})
class FooCmp {...}
// Indirect export of FooCmp
export {FooCmp};
```
This is not an immediate problem for most application builds, since the
default value for `compileNonExportedClasses` is `true` and therefore such
classes get compiled regardless.
However, in the Angular Language Service now, `compileNonExportedClasses` is
forcibly overridden to `false`. That's because the tsconfig used by the IDE
and Language Service is often far broader than the application build's
configuration, and pulls in test files that can contain unexported classes
not designed with AOT compilation in mind.
Therefore, the Language Service has trouble working with such structures.
In this commit, the `ReflectionHost` gains a new API for detecting whether a
class is exported. The implementation of this method now not only considers
the `export` modifier, but also scans the `ts.SourceFile` for indirect
exports like the example above. This ensures the above case will be
processed directly in the Language Service.
This new operation is cached using an expando symbol on the `ts.SourceFile`,
ensuring good performance even when scanning large source files with lots of
exports (e.g. a FESM file under `ngcc`).
Fixes#42184.
PR Close#42207
We were linting against usages of `fdescribe` and `fit` by referencing the `no-jasmine-focus` rule which isn't installed, causing tslint to log the following:
```
Could not find implementations for the following rules specified in the configuration:
no-jasmine-focus
Try upgrading TSLint and/or ensuring that you have all necessary custom rules installed.
If TSLint was recently upgraded, you may have old rules configured which need to be cleaned
```
These changes switch to using the built-in `ban` rule.
PR Close#42415
Previously the docs were very minimalistic. The most important thing missing from the docs
was that people should primarily use higher level APIs instead of using ROUTES directly.
It would be nice to holistically overhaul more of the router API docs, but that's out of
scope of this change.
Fixes#39350
PR Close#42398
An internal change in Ivy has surfaced issues in previosly broken code. This change adds a note to the
Ivy compatibility guide as well as the TrackByFunction api docs.
Fixes#35896
PR Close#42338
The list for the possible options of providedIn was not totally clear. This commit ensures each possible value is included explicitly in the docs.
fixes#29330
PR Close#42355
We have some internal proxies for all of the Jasmine functions, as well as some other helpers. This code hasn't been touched in more than 5 years, it can lead to confusion and it isn't really necessary since the same can be achieved using Jasmine.
These changes remove most of the code and clean up our existing unit tests.
PR Close#42177
Most of these were fixed in other PRs but there were are couple of stragglers.
Note that `my-app` components in non-documentation facing code, such as
compliance tests have not been changed.
Fixes#20235
PR Close#42256
This commit fixes the state of variable _started on call of reset method.
Earlier behaviour was on call of `reset()` method we are not setting back
`_started` flag's value to false and it created various issue for end user
which were expecting this behaviour as per name of method.
We provided end user `reset()` method, but it was empty method and on call
of it wasn't doing anything. As end user/developer were not able to
reuse animation not animation after call of reset method.
In this PR on call of `reset()` method we are setting flag `_started` value to false
which can be accessed by `hasStarted()`.
Resolves#18140
PR Close#41608
`Location.go` does not trigger the browser's `popstate` event because
the Angular Router uses `pushState` and `replaceState`. This can be
confusing when calling `Location.go` and using `Location.subscribe`.
This commit clarifies the behavior of `Location.subscribe` and points
developers to the `onUrlChanges` subscription instead.
Fixes#12691
PR Close#42272
Add small clarity to sentence in documentation for navigation cancel event
to indicate that router guards returning false or urlTree is only one of
several reasons a NavigationCancel event happens.
fixes#26613
PR Close#42282
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
This commit clarifies the description of the default `pathMatch`
strategy (prefix) to indicate that the path segments must each match to
a config.
fixes#39737
PR Close#42287
With this change we add a migration to replace the deprecated shadow-piercing selector from `/deep/` with deprecated but recommended `::ng-deep`.
The main motivation for this change is that the CSS optimizer CSSNano which is used by the Angular CLI no longer supports this non standard selector and causes build time errors due to the selector being minified incorrectly. However, CSSNano does support the recommended deprecated `::ng-deep` selector.
Closes: #42196
PR Close#42214
Remove publishConfig property from the package.json entry for each of the entries in
the publish configuration. Using the wombat proxy is now ensured/managed by the
ng-dev release tooling.
PR Close#42104
TypeScript supports ECMAScript private identifiers. It can happen that
developers intend to access such members from within an expression.
This currently results in an unclear error from the lexer. e.g.
```
'Parser Error: Unexpected token # at column 1 in [{{#myField}}] in C:/test.ts@5:2
```
We could improve such errors by tokenizing private identifiers similar to
how the TypeScript scanner processes them. Later we can report better
errors in the expression parser or in the typecheck block. This commit
causes all private identifier tokens to be disallowed, so it never
reaches the type checker. This is done intentionally as private
identifiers should not be considered valid Angular syntax, especially
because private fields are not guaranteed to be accessible from within
a component/directive definition (e.g. there cases where a template
function is generated outside of the class; which results in private
members not being accessible; and this results in mixed/confusing
behavior).
Fixes#36003.
PR Close#42027
We skip event listeners on non-element host nodes (e.g. `ng-container` or `ng-element`), because they don't map to a DOM node so there's nothing to bind the event to. The problem is that this also prevents listeners bound to global targets from being bound.
These changes add an extra condition to allow for the event to be bound if it has a custom event target resolver.
Fixes#14191.
PR Close#42014
* recently, performance events started showing up with a -bpstart and -bpend
suffix to indicate their being the start and end events for our performance
testing. to fix this, we added an additional check for those suffixes in
addition to the old checks.
PR Close#42085
The Validator and AsyncValidator interfaces provide a callback, `registerOnValidatorChange(fn)`. `registerOnValidatorChange` is supposed to be fired at least once to register `fn` with the validator. `fn` is then called by the validator whenever its inputs change. This was previously not happening for FormGroup validators, and is now fixed.
PR Close#41971
Prior to this change, any inserted `<style>` nodes into shadow dom trees would be retained
in memory, even after the shadow dom tree has been removed. This commit fixes the memory
leak by tracking the inserted `<style>` nodes per host element, such that removal of the
host element also releases the style nodes.
Fixes#36655
PR Close#42005
The JIT compiler has a mapping from component to the owning NgModule
and tracks whether a certain NgModule class has been verified; these
maps causes any JIT compiled component and NgModule to be retained even
if they are no longer referenced from anywhere else. This commit
switches the maps to `WeakMap` to allow garbage collecting any
components and NgModules that are no longer referenced elsewhere.
Fixes#19997
PR Close#42003
Now that there is no need to work around the source-map bug in TypeScript
(https://github.com/Microsoft/TypeScript/issues/29300) we can just use
`resolvedTemplateUrl` for the source-map URL, rather than having a separate
property.
PR Close#42000
Indirect templates are templates produced by a non-literal expression value
of the `template` field in `@Component`. The compiler can statically
determine the template string, but there is not guaranteed to be a physical
file which contains the bytes of the template string. For example, the
template string may be computed by a concatenation expression: 'a' + 'b'.
Previously, the compiler would use the TS file path as the source map path
for indirect templates. This is incorrect, however, and breaks source
mapping for such templates, since the offsets within the template string do
not correspond to bytes of the TS file.
This commit returns the compiler to its old behavior for indirect templates,
which is to use `''` as the source map URL for such templates.
Fixes#40854
PR Close#41973
URLSearch params are by default supported in the browser but are not supported by angular/http package added support for URLSearchParams
Fixes#36317
PR Close#37852
Rather than de-duplicating results as we build them, a final de-duplication can be done at the end.
This way, there's no forgetting to de-duplicate results at some level.
Prior to this commit, results from template locations that mapped to
multiple different typescript locations would not be de-duplicated (e.g.
an input binding that is bound to two separate directives).
PR Close#40523
When `checkTypeOfPipes` is set to `false`, our TCB currently generates
the a statement like the following when pipes appear in the template:
`(_pipe1 as any).transform(args)`
This did enable us to get _some_ information from the Language Service
about pipes in this case because we still had access to the pipe
instance. However, because it is immediately cast to `any`, we cannot
get type information about the transform access. That means actions like "go to
definition", "find references", "quick info", etc. will return
incomplete information or fail altogether.
Instead, this commit changes the TCB to generate `(_pipe1.transform as any)(args)`.
This gives us the ability to get complete information for the LS
operations listed above.
PR Close#40523
This commit updates the logic in the LS renaming to handle renaming of
pipes, both from the name expression in the pipe metadata as well as
from the template.
The approach here is to introduce a new concept for renaming: an
"indirect" rename. In this type of rename, we find rename locations
in with the native TS Language Service using a different node than the
one we are renaming. Using pipes as an example, if we want to rename the
pipe name from the string literal expression, we use the transform
method to find rename locations rather than the string literal itself
(which will not return any results because it's just a string).
So the general approach is:
* Determine the details about the requested rename location, i.e. the
targeted template node and symbol for a template rename, or the TS
node for a rename outside a template.
* Using the details of the location, determine if the node is attempting
to rename something that is an indirect rename (pipes, selectors,
bindings). Other renames are considered "direct" and we use whatever
results the native TSLS returns for the rename locations.
* In the case of indirect renames, we throw out results that do not
appear in the templates (in this case, the shim files). These results will be
for the "indirect" rename that we don't want to touch, but are only
using to find template results.
* Create an additional rename result for the string literal expression
that is used for the input/output alias, the pipe name, or the
selector.
Note that renaming is moving towards being much more accurate in its
results than "find references". When the approach for renaming
stabilizes, we may want to then port the changes back to being shared
with the approach for retrieving references.
PR Close#40523
This commit renames the files for the references and rename functionality to indicate
that they deal with _both_ references and rename, not just references.
PR Close#40523
Paul Gschwendtner
Andrew Scott
Andrew Kushnir
Kristiyan Kostadinov
Pete Bacon Darwin
Renovate Bot
Jessica Janiuk
Dylan Hunn
JoostK
iRealNirmal
Vahid Mohammadi
Alex Rickabaugh
Igor Minar
Joey Perrott
Kapunahele Wong
Alan Agius
David Shevitz
MrJithil
wagnermaciel
Julien Marcou
Ajit Singh
mgechev