Prior to ivy, undefined values passed in an object to the
ngStyle directive were ignored. Restore this behavior by
ignoring keys that point to undefined values.
closes#34310
PR Close#34422
Expressions in an inline template binding are improperly recorded as
spaning an offset calculated from the start of the template binding
attribute key, whereas they should be calculated from the start of the
attribute value, which contains the actual binding AST.
PR Close#31813
There were some extra examples for `downgradeComponent()` in the upgrade
guide. Added a link to the relevant section of the guide in the
`downgradeComponent()` docs.
Fixes#31584
PR Close#34406
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:
1. Updating the R3 switches to use POST_R3 by default. At first glance,
this doesn't look easy because the current ngtsc switch logic seems to
be unidirectional (only PRE_R3 to POST_R3).
2. Updating the legacy setup to run with Ivy. This sounds like the easiest
solution at first.. but it turns out to be way more complicated. Packages
would need to be built with ngtsc using legacy tools (i.e. first building
the compiler-cli; and then building packages) and View Engine only tests
would need to be determined and filtered out. Basically it will result in
re-auditing all test targets. This is contradictory to the fact that we have
this information in Bazel already.
3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
fine-grained test targets that should run. This would be a good start
(e.g. acceptance tests) and also would mean that we do not continue maintaining
the legacy setup..
This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.
PR Close#34277
When we log DI errors we get the name of the provider via `SomeClass.name`. In IE functions that inherit from other functions don't have their own `name`, but they take the `name` from the lowest parent in the chain, before `Function`. I've added some changes to fall back to parsing out the function name from the function's string form.
PR Close#34305
The way definitions are added in JIT mode is through `Object.defineProperty`, but the problem is that in IE10 properties defined through `defineProperty` won't be inherited which means that inheriting injectable definitions no longer works. These changes add a workaround only for JIT mode where we define a fallback method for retrieving the definition. This isn't ideal, but it should only be required until v10 where we'll no longer support inheriting injectable definitions from undecorated classes.
PR Close#34305
In JIT mode we use `__proto__` when reading constructor parameter metadata, however it's not supported on IE10. These changes switch to using `Object.getPrototypeOf` instead.
PR Close#34305
We've got some tests that assert that the generate DOM looks correct. The problem is that IE changes the attribute order in `innerHTML` which caused the tests to fail. I've reworked the relevant tests not to assert directly against `innerHTML`.
PR Close#34305
We have a couple of cases where we use something like `typeof Node === 'function'` to figure out whether we're in a worker context. This works in most browsers, but IE returns `object` instead of `function`. I've updated all the usages to account for it.
PR Close#34305
In `DebugElement.attributes` we return all of the attributes from the underlying DOM node. Most browsers change the attribute names to lower case, but IE preserves the case and since we use camel-cased attributes, the return value was inconsitent. I've changed it to always lower case the attribute names.
PR Close#34305
While sanitizing on browsers that don't support the `template` element (pretty much only IE), we create an inert document and we insert content into it via `document.body.innerHTML = unsafeHTML`. The problem is that IE appears to parse the HTML passed to `innerHTML` differently, depending on whether the element has been inserted into a document or not. In particular, it seems to split some strings into multiple text nodes, which would've otherwise been a single node. This ended up throwing off some of the i18n code down the line and causing a handful of failures. I've worked around it by creating a new inert `body` element into which the HTML would be inserted.
PR Close#34305
A quirk of the Angular template parser is that when parsing templates in the
"default" mode, with options specified by the user, the source mapping
information in the template AST may be inaccurate. As a result, the compiler
parses the template twice: once for "emit" and once to produce an AST with
accurate sourcemaps for diagnostic production.
Previously, only the first parse was performed during analysis. The second
parse occurred during the template type-checking phase, just in time to
produce the template type-checking file.
However, with the reuse of analysis results during incremental builds, it
makes more sense to do the diagnostic parse eagerly during analysis so that
the work isn't unnecessarily repeated in subsequent builds. This commit
refactors the `ComponentDecoratorHandler` to do both parses eagerly, which
actually cleans up some complexity around template parsing as well.
PR Close#34334
Avoids the usage of array destructuring, as it introduces calls to
a `__values` helper function in ES5 that has a relatively high
performance impact. This shaves off roughly 130ms of CPU time for a
large compilation with big templates that uses i18n.
PR Close#34332
The template parser has a certain interpolation config associated with
it and builds a regular expression each time it needs to extract the
interpolations from an input string. Since the interpolation config is
typically the default of `{{` and `}}`, the regular expression doesn't
have to be recreated each time. Therefore, this commit creates only a
single regular expression instance that is used for the default
configuration.
In a large compilation unit with big templates, computing the regular
expression took circa 275ms. This change reduces this to effectively
zero.
PR Close#34332
On a large compilation unit with big templates, the total time spent in
the `PlainCharacterCursor` constructor was 470ms. This commit applies
two optimizations to reduce this time:
1. Avoid the object spread operator within the constructor, as the
generated `__assign` helper in the emitted UMD bundle (ES5) does not
optimize well compared to a hardcoded object literal. This results in a
significant performance improvement. Because of the straight-forward
object literal, the VM is now much better able to optimize the memory
allocations which makes a significant difference as the
`PlainCharacterCursor` constructor is called in tight loops.
2. Reduce the number of `CharacterCursor` clones. Although cloning
itself is now much faster because of the optimization above, several
clone operations were not necessary.
Combined, these changes reduce the total time spent in the
`PlainCharacterCursor` constructor to just 10ms.
PR Close#34332
During TypeScript module resolution, a lot of filesystem requests are
done. This is quite an expensive operation, so a module resolution cache
can be used to speed up the process significantly.
This commit lets the Ivy compiler perform all module resolution with a
module resolution cache. Note that the module resolution behavior can be
changed with a custom compiler host, in which case that custom host
implementation is responsible for caching. In the case of the Angular
CLI a custom compiler host with proper module resolution caching is
already in place, so the CLI already has this optimization.
PR Close#34332
The export scope of NgModules from external compilations units, as
present in .d.ts declarations, does not change during a compilation so
can be easily shared. There was already a cache but the computed export
scope was not actually stored there. This commit fixes that.
PR Close#34332
To create a binding parser, an instance of `ElementSchemaRegistry` is
required. Prior to this change, each time a new binding parser was
created a new instance of `DomElementSchemaRegistry` would be
instantiated. This is an expensive operation that takes roughly 1ms per
instantiation, so it is key that multiple allocations are avoided.
By sharing a single `DomElementSchemaRegistry`, we avoid two such
allocations, i.e. save ~2ms, per component template.
PR Close#34332
Previously the calls to run the schematics were not being properly
or consistently awaited in the tests. While this currently does not
affect the tests' performance, this fix corrects the syntax and
adds stability for future changes.
PR Close#34364
In Ivy it's illegal for a template to write to a template variable. So the
template:
```html
<ng-template let-somevar>
<button (click)="somevar = 3">Set var to 3</button>
</ng-template>
```
is erroneous and previously would fail to compile with an assertion error
from the `TemplateDefinitionBuilder`. This error wasn't particularly user-
friendly, though, as it lacked the context of which template or where the
error occurred.
In this commit, a new check in template type-checking is added which detects
such erroneous writes and produces a true diagnostic with the appropriate
context information.
Closes#33674
PR Close#34339
Previously, the compiler performed an incremental build by analyzing and
resolving all classes in the program (even unchanged ones) and then using
the dependency graph information to determine which .js files were stale and
needed to be re-emitted. This algorithm produced "correct" rebuilds, but the
cost of re-analyzing the entire program turned out to be higher than
anticipated, especially for component-heavy compilations.
To achieve performant rebuilds, it is necessary to reuse previous analysis
results if possible. Doing this safely requires knowing when prior work is
viable and when it is stale and needs to be re-done.
The new algorithm implemented by this commit is such:
1) Each incremental build starts with knowledge of the last known good
dependency graph and analysis results from the last successful build,
plus of course information about the set of files changed.
2) The previous dependency graph's information is used to determine the
set of source files which have "logically" changed. A source file is
considered logically changed if it or any of its dependencies have
physically changed (on disk) since the last successful compilation. Any
logically unchanged dependencies have their dependency information copied
over to the new dependency graph.
3) During the `TraitCompiler`'s loop to consider all source files in the
program, if a source file is logically unchanged then its previous
analyses are "adopted" (and their 'register' steps are run). If the file
is logically changed, then it is re-analyzed as usual.
4) Then, incremental build proceeds as before, with the new dependency graph
being used to determine the set of files which require re-emitting.
This analysis reuse avoids template parsing operations in many circumstances
and significantly reduces the time it takes ngtsc to rebuild a large
application.
Future work will increase performance even more, by tackling a variety of
other opportunities to reuse or avoid work.
PR Close#34288
Previously 'analyze' in the various `DecoratorHandler`s not only extracts
information from the decorators on the classes being analyzed, but also has
several side effects within the compiler:
* it can register metadata about the types involved in global metadata
trackers.
* it can register information about which .ngfactory symbols are actually
needed.
In this commit, these side-effects are moved into a new 'register' phase,
which runs after the 'analyze' step. Currently this is a no-op refactoring
as 'register' is always called directly after 'analyze'. In the future this
opens the door for re-use of prior analysis work (with only 'register' being
called, to apply the above side effects).
Also as part of this refactoring, the reification of NgModule scope
information into the incremental dependency graph is moved to the
`NgtscProgram` instead of the `TraitCompiler` (which now only manages trait
compilation and does not have other side effects).
PR Close#34288
Prior to this commit, the `IvyCompilation` tracked the state of each matched
`DecoratorHandler` on each class in the `ts.Program`, and how they
progressed through the compilation process. This tracking was originally
simple, but had grown more complicated as the compiler evolved. The state of
each specific "target" of compilation was determined by the nullability of
a number of fields on the object which tracked it.
This commit formalizes the process of compilation of each matched handler
into a new "trait" concept. A trait is some aspect of a class which gets
created when a `DecoratorHandler` matches the class. It represents an Ivy
aspect that needs to go through the compilation process.
Traits begin in a "pending" state and undergo transitions as various steps
of compilation take place. The `IvyCompilation` class is renamed to the
`TraitCompiler`, which manages the state of all of the traits in the active
program.
Making the trait concept explicit will support future work to incrementalize
the expensive analysis process of compilation.
PR Close#34288
Previously the UMD rendering formatter assumed that
there would already be import (and an export) arguments
to the UMD factory function.
This commit adds support for this corner case.
Fixes#34138
PR Close#34353
This reverts commit 73fd10ddd5548ce899b897ba2779ff041914c2dc because it's part
of a PR that was red on CircleCI once it was merged into master (Windows tests
are only run on master, not on PRs).
PR Close#34360
This reverts commit 6b905347bd2294bba703f6d38c983356af58946b because it's part
of a PR that was red on CircleCI once it was merged into master (Windows tests
are only run on master, not on PRs).
PR Close#34360
This reverts commit 4e38a973b158ba397903199abe1e008b0627d81c because it's part of a PR
that was red on CircleCI once it was merged into master (Windows tests are only run
on master, not on PRs).
PR Close#34360
When statically evalulating UMD code it is possible to find
that we are looking for the declaration of an identifier that
actually came from a typings file (rather than a UMD file).
Previously, the UMD reflection host would always try to use
a UMD specific algorithm for finding identifier declarations,
but when the id is actually in a typings file this resulted in the
returned declaration being the containing file of the declaration
rather than the declaration itself.
Now the UMD reflection host will check to see if the file containing
the identifier is a typings file and use the appropriate stategy.
PR Close#34356
The `loadTranslations()` function will attach the `translate()` function
to `$localize.translate` to cause runtime translation to occur.
We should cleanup after ourselves by unattaching this function when
we call `clearTranslations()`.
Fixes#32781
PR Close#34346
This release brings a bug fix that https://github.com/angular/angular/pull/34243 is waiting on in order to remove rules_nodejs patches: fix(builtin): additional_root_paths in pkg_web should also include paths in genfiles and bin dirs (bazelbuild/rules_nodejs#1402)
PR Close#34112
This commit fixes a couple issues that prevent `class_binding` benchmark from running: moving constants requires by the `benchmark` function before function declaration and referencing correct consts in template instructions.
PR Close#34242
The `ModuleWithProviders` type has an optional type parameter that
should be specified to indicate what NgModule class will be provided.
This enables the Ivy compiler to statically determine the NgModule type
from the declaration files. This type parameter will become required in
the future, however to aid in the migration the compiler will detect
code patterns where using `ModuleWithProviders` as return type is
appropriate, in which case it transforms the emitted .d.ts files to
include the generic type argument.
This should reduce the number of occurrences where `ModuleWithProviders`
is referenced without its generic type argument.
Resolves FW-389
PR Close#34235
This commit refactors the way the compiler transforms .d.ts files during
ngtsc builds. Previously the `IvyCompilation` kept track of a
`DtsFileTransformer` for each input file. Now, any number of
`DtsTransform` operations that need to be applied to a .d.ts file are
collected in the `DtsTransformRegistry`. These are then ran using a
single `DtsTransformer` so that multiple transforms can be applied
efficiently.
PR Close#34235
The metadata collector for View Engine compilations emits error symbols
for static class members that have not been initialized, which prevents
a library from building successfully when `strictMetadataEmit` is
enabled, which is recommended for libraries to avoid issues in library
consumers. This is troublesome for libraries that are adopting static
members for the Ivy template type checker: these members don't need a
value assignment as only their type is of importance, however this
causes metadata errors. As such, a library used to be required to
initialize the special static members to workaround this error,
undesirably introducing a code-size overhead in terms of emitted
JavaScript code.
This commit modifies the collector logic to specifically ignore
the special static members for Ivy's template type checker, preventing
any errors from being recorded during the metadata collection.
PR Close#34296
For Ivy's template type checker it is possible to let a directive
specify static members to allow a wider type for some input:
```typescript
export class MatSelect {
@Input() disabled: boolean;
static ngAcceptInputType_disabled: boolean | string;
}
```
This allows a binding to the `MatSelect.disabled` input to be of type
boolean or string, whereas the `disabled` property itself is only of
type boolean.
Up until now, any static `ngAcceptInputType_*` property was not
inherited for subclasses of a directive class. This is cumbersome, as
the directive's inputs are inherited, so any acceptance member should as
well. To resolve this limitation, this commit extends the flattening of
directive metadata to include the acceptance members.
Fixes#33830
Resolves FW-1759
PR Close#34296
TypeScript 3.7 flags `if` conditions that implicitly coerce a function/method definition. While checking for the `template` presence on a def (actually checking whether we work with Component) in `saveNameToExportMap`, the `if` condition had implicit type coercion. This commit updates the condition to use the `isComponentDef` function (that checks `def.template` against `null` internally) to avoid compilation errors with TypeScript 3.7.
PR Close#34335
Prior to this commit, values wrapped into SafeStyle were not handled correctly in [style.prop] bindings in case style sanitizer is present (when template contains some style props that require sanitization). Style sanitizer was not unwrapping values in case a given prop doesn't require sanitization.As a result, wrapped values were used as final styling values (see https://github.com/angular/angular/blob/master/packages/core/src/render3/styling/bindings.ts#L620). This commit updates the logic to unwrap safe values in sanitizer in case no sanitization is required.
PR Close#34286
The undecorated child migration creates a synthetic decorator, which
contained `"exportAs": ["exportName"]` as obtained from the metadata of
the parent class. This is a problem, as `exportAs` needs to specified
as a comma-separated string instead of an array. This commit fixes the
bug by transforming the array of export names back to a comma-separated
string.
PR Close#34014
When ngcc is analyzing synthetically inserted decorators from a
migration, it is typically not expected that any diagnostics are
produced. In the situation where a diagnostic is produced, however, the
diagnostic would not be reported at all. This commit ensures that
diagnostics in migrations are reported.
PR Close#34014
The compiler exports a `formatDiagnostics` function which consumers can use
to print both ts and ng diagnostics. However, this function was previously
using the "old" style TypeScript diagnostics, as opposed to the modern
diagnostic printer which uses terminal colors and prints additional context
information.
This commit updates `formatDiagnostics` to use the modern formatter, plus to
update Ivy's negative error codes to Angular 'NG' errors.
The Angular CLI needs a little more work to use this function for printing
TS diagnostics, but this commit alone should fix Bazel builds as ngc-wrapped
goes through `formatDiagnostics`.
PR Close#34234
Occasionally a factory function needs to be generated for an "invalid"
constructor (one with parameters types which aren't injectable). Typically
this happens in JIT mode where understanding of parameters cannot be done in
the same "up-front" way that the AOT compiler can.
This commit changes the JIT compiler to generate a new `invalidFactoryDep`
call for each invalid parameter. This instruction will error at runtime if
called, indicating both the index of the invalid parameter as well as (via
the stack trace) the factory function which was generated for the type being
constructed.
Fixes#33637
PR Close#33739
In Ivy, if you do:
`TestBed.configureTestingModule({providers: [{provide: Service}]});`
the injector will attempt to inject Service as if it was simply listed
in the providers array like `{providers: [Service]}`
This fixes an inconsistency when similarly providing an override with no
`useValue` or `useFactory`.
PR Close#33769
Previously the JIT evaluated code for ivy localized strings included
backtick tagged template strings, which are not compatible with ES5
in legacy browsers such as IE 11.
Now the generated code is ES5 compatible.
Fixes#34246
PR Close#34265
Prior to this commit, calling change detection for destroyed views resulted in errors being thrown in some cases. This commit adds a check to make sure change detection is invoked for non-destroyed views only.
PR Close#34241
Previously, ternary expressions were emitted as:
condExpr ? trueCase : falseCase
However, this causes problems when ternary operations are nested. In
particular, a template expression of the form:
a?.b ? c : d
would have compiled to:
a == null ? null : a.b ? c : d
The ternary operator is right-associative, so that expression is interpreted
as:
a == null ? null : (a.b ? c : d)
when in reality left-associativity is desired in this particular instance:
(a == null ? null : a.b) ? c : d
This commit adds a check in the expression translator to detect such
left-associative usages of ternaries and to enforce such associativity with
parentheses when necessary.
A test is also added for the template type-checking expression translator,
to ensure it correctly produces right-associative expressions for ternaries
in the user's template.
Fixes#34087
PR Close#34221
Remove the remaining check for compile build variable in the ng_module
rule. Now that components is no longer relying on this build variable
we can safely remove it from our repository.
We will leave the remaining check for if the compile build variable is
used within our own repo, with plans to remove it in a couple months.
It is being kept in place to ensure that uncommitted local scripts for
our own development that we have locally, kill error as expected if
they still reference the compile build variable.
PR Close#34280
Adds the ability to expose global symbols in the API docs via the `@globalApi` tag. Also supports optionally setting a namespace which will be added to the name automatically (e.g. `foo` will be renamed to `ng.foo`). Relevant APIs should also be exported through the `global.ts` file which will show up under `core/global`.
PR Close#34237
Due to a bug in the existing banner, `typescript` module was require-d
instead of reusing the module passed in from tsserver.
This bug is caused by some source files in language-service that imports
`typescript` instead of `typescript/lib/tsserverlibrary`.
This is not an unsupported use case, it's just that when typescript is
resolved in the banner we have to be very careful about which modules to
"require".
The convoluted logic in the banner makes it very hard to detect
anomalies. This commit cleans it up and removes a lot of unneeded code.
This commit also removes `ts` import in typescript_host.ts and use `tss`
instead to make it less confusing.
PR Close#34262
This commit creates a way for `ng_module` rule to compile with Ivy based
on the `ivy` attribute. This enables google3 targets to pick the
compiler without using `define` flags.
PR Close#34238
Previously, create_angular_testing_module would export a mutable `let`
binding. The binding is already exporting using an accessor function
though, so the export on the let variable seems like an accidental
oversight.
This is functionally equivalent, but makes it easier for module
optimizers such as Closure Compiler to track down side effects and prune
modules.
PR Close#34232
Previously, browser_util would export a mutable `let` binding that was
initialized as a side-effect of `BrowserDetection.setup()`. This change
refactors the mutable binding into a `const` binding that is immediately
initialized in its initialized.
This is functionally equivalent, but makes it easier for module
optimizers such as Closure Compiler to track down side effects and prune
modules. It is also arguably cleaner to read (no worries about later
changes to the apparently mutable but effectively const binding).
PR Close#34207
Previously the `rootDir` was set to the entry-point path but
this is incorrect if the source files are stored in a directory outside
the entry-point path. This is the case in the latest versions of the
Angular CDK.
Instead the `rootDir` should be the containing package path, which is
guaranteed to include all the source for the entry-point.
---
A symptom of this is an error when ngcc is trying to process the source of
an entry-point format after the entry-point's typings have already been
processed by a previous processing run.
During processing the `_toR3Reference()` function gets called which in turn
makes a call to `ReflectionHost.getDtsDeclaration()`. If the typings files
are also being processed this returns the node from the dts typings files.
But if we have already processed the typings files and are now processing
only an entry-point format without typings, the call to
`ReflectionHost.getDtsDeclaration()` returns `null`.
When this value is `null`, a JS `valueRef` is passed through as the DTS
`typeRef` to the `ReferenceEmitter`. In this case, the `ReferenceEmitter`
fails during `emit()` because no `ReferenceEmitStrategy` is able to provide
an emission:
1) The `LocalIdentifierStrategy` is not able help because in this case
`ImportMode` is `ForceNewImport`.
2) The `LogicalProjectStrategy` cannot find the JS file below the `rootDir`.
The second strategy failure is fixed by this PR.
Fixes https://github.com/angular/ngcc-validation/issues/495
PR Close#34212
When directionality data was added to @angular/common locales, only
the externally used locales were updated. We need to additionally
update the closure locales which are synced into google3.
PR Close#34240
Commit that updated i18n message ids rendering (e524322c43) also introduced a couple tests that relied on a previous version of `ngI18nClosureMode` flag format. The `ngI18nClosureMode` usage format was changed in the followup commit (c4ce24647b) and triggered a problem with the mentioned tests. This commit updates the tests to a new `ngI18nClosureMode` flag usage format.
PR Close#34224
If the `ngI18nClosureMode` global check actually makes it
through to the runtime, then checks for its existence should
be guarded to prevent `Reference undefined` errors in strict
mode.
(Normally, it is stripped out by dead code elimination during
build optimization.)
This comment ensures that generated template code guards
this global check.
PR Close#34211
If the `ngI18nClosureMode` global check actually makes it
through to the runtime, then checks for its existence should
be guarded to prevent `Reference undefined` errors in strict
mode.
(Normally, it is stripped out by dead code elimination during
build optimization.)
PR Close#34211
This is a follow-up to #33997 where some new generic parameters were added without defaults which is technically a breaking change. These changes add the defaults.
PR Close#34206
Prior to this commit, there was no check in R3TestBed to verify that metadata is resolved using a given Type. That leads to some cryptic error messages (when TestBed tries to compile a Type without having metadata) in case TestBed override functions receive unexpected Types (for example a Directive is used in `TestBed.overrideComponent` call). This commit adds the necessary checks to verify metadata presence before TestBed tries to (re)compile a Type.
PR Close#34204
Prior to this commit, if a template (for example, generated using structural directive such as *ngIf) contains `ngProjectAs` attribute, it was not included into attributes array in generated code and as a result, these templates were not matched at runtime during content projection. This commit adds the logic to append `ngProjectAs` values into corresponding element's attribute arrays, so content projection works as expected.
PR Close#34200
Prior to this commit, i18n runtime code failed with the exception saying that no provider was found for ChangeDetectorRef for a pipe used in ICU. The problem happened because the underlying `createViewRef` function was not taking into account IcuContainer as a valid TNodeType. This commit updates the `createViewRef` function to return corresponding ViewRef for TNodeType.IcuContainer.
PR Close#34198
Includes a few minor performance improvements:
* In the `nextContext` instruction we assign a new LView to the `LFrame.contextLView` and then we immediately look it up to get its context. We don't need to do that since we know the view that was assigned already.
* Removes the default value for the `level` parameter of `nextContextImpl` because it generates more code in es5 and is internal-only.
* Removes the default parameter from `setActiveHostElement` since it generates extra code and it's an internal function.
* Makes a check in `setElementExitFn` more strict since we're guaranteed for the value to match the type.
PR Close#34183
Fixes ngtsc incorrectly logging an unknown element diagnostic for HTML elements that are inside an SVG `foreignObject` with the `xhtml` namespace.
Fixes#34171.
PR Close#34178
It is possible for HTML formatters to add whitespace
around the content of `i18n` attribute values. This can
make the meaning and custom ids brittle to simple
whitespace formatting.
This commit ensures that the metadata string extracted
from HTML `i18n` attributes is trimmed before being parsed
into meaning, description and custom id.
PR Close#34154
By ensuring that legacy i18n message ids are rendered into the templates
of components for packages processed by ngcc, we ensure that these packages
can be used in an application that may provide translations in a legacy
format.
Fixes#34056
PR Close#34135
Placing this configuration in to the bundle avoids having to pass the
value around through lots of function calls, but also could enable
support for different behaviour per bundle in the future.
PR Close#34135
Now that `@angular/localize` can interpret multiple legacy message ids in the
metablock of a `$localize` tagged template string, this commit adds those
ids to each i18n message extracted from component templates, but only if
the `enableI18nLegacyMessageIdFormat` is not `false`.
PR Close#34135
This change will enable the Angular compiler to provide these legacy
message ids by default, which will solve problems with ngcc not knowing
whether to generate legacy ids or not.
PR Close#34135
When first written there was no way to specify the raw text when
programmatically creating a template tagged literal AST node.
This is now fixed in TS and so the hack is no longer needed.
PR Close#34135
We should only generate the `providedIn` property in injectable
defs if it has a non-null value. `null` does not communicate
any information to the runtime that isn't communicated already
by the absence of the property.
This should give us some modest code size savings.
PR Close#34116
Michael Nahkies
Ayaz Hafiz
JoostK
ajitsinghkaler
Paul Gschwendtner
crisbeto
Pawel Kozlowski
Alex Rickabaugh
Adam Plumer
Pete Bacon Darwin
Kara Erickson
Greg Magolan
Keen Yee Liau
Andrew Kushnir
Misko Hevery
Jithil P Ponnan
Andrew Scott
Joey Perrott
Keen Yee Liau
ivanwonder
Martin Probst
zuckjet
arturovt
Feliks Khantsis
JiaLiPassion
Danny Skoog