Skip to content
Permalink
Branch: master
Commits on Apr 25, 2019
  1. fix(ivy): don't include query fields in type constructors (#30094)

    alxhub authored and AndrewKushnir committed Apr 24, 2019
    Previously, ngtsc included query fields in the list of fields which can
    affect the type of a directive via its type constructor. This feature
    however has yet to be built, and View Engine in default mode does not
    do this inference.
    
    This caused an unexpected bug where private query fields (which should be
    an error but are allowed by View Engine) cause the type constructor
    signature to be invalid. This commit fixes that issue by disabling the
    logic to include query fields.
    
    PR Close #30094
  2. fix(ivy): generate default 'any' types for type ctor generic params (#…

    alxhub authored and AndrewKushnir committed Apr 24, 2019
    …30094)
    
    ngtsc generates type constructors which infer the type of a directive based
    on its inputs. Previously, a bug existed where this inference would fail in
    the case of 'any' input values. For example, the inference of NgForOf fails
    when an 'any' is provided, as it causes TypeScript to attempt to solve:
    
    T[] = any
    
    In this case, T gets inferred as {}, the empty object type, which is not
    desirable.
    
    The fix is to assign generic types in type constructors a default type of
    'any', which TypeScript uses instead of {} when inference fails.
    
    PR Close #30094
  3. feat(router): deprecate loadChildren:string (#30073)

    alxhub authored and AndrewKushnir committed Apr 23, 2019
    The proposed ES dynamic import() is now supported by the Angular CLI and the
    larger toolchain. This renders the `loadChildren: string` API largely
    redundant, as import() is far more natural, is less error-prone, and is
    standards compliant. This commit deprecates the `string` form of
    `loadChildren` in favor of dynamic import().
    
    DEPRECATION:
    
    When defining lazy-loaded route, Angular previously offered two options for
    configuring the module to be loaded, both via the `loadChildren` parameter
    of the route. Most Angular developers are familiar withthe `string` form of
    this API. For example, the following route definition configures Angular to
    load a `LazyModule` NgModule from `lazy-route/lazy.module.ts`:
    
    ```
    [{
      path: 'lazy',
      loadChildren: 'lazy-route/lazy.module#LazyModule',
    }]
    ```
    
    This "magic string" configuration was previously necessary as there was
    no dynamic module loading standard on the web. This has changed with the
    pending standardization of dynamic `import()` expressions, which are now
    supported in the Angular CLI and in web tooling in general. `import()`
    offers a more natural and robust solution to dynamic module loading. The
    above example can be rewritten to use dynamic `import()`:
    
    ```
    [{
      path: 'lazy',
      loadChildren: () => import('./lazy-route/lazy.module').then(mod => mod.LazyModule),
    }]
    ```
    
    This form of lazy loading offers significant advantages in terms of:
    
    * type checking via TypeScript
    * simplicity of generated code
    * future potential to run natively in supporting browsers
      (see: [caniuse: dynamic import()](https://caniuse.com/#feat=es6-module-dynamic-import))
    
    As a result, Angular is deprecating the `loadChildren: string` syntax in
    favor of ES dynamic `import()`. An automatic migration will run during
    `ng upgrade` to convert your existing Angular code to the new syntax.
    
    PR Close #30073
Commits on Apr 24, 2019
  1. fix(ivy): don't reuse a ts.Program more than once in ngtsc (#30090)

    alxhub authored and AndrewKushnir committed Apr 24, 2019
    ngtsc previously could attempt to reuse the main ts.Program twice. This
    occurred when template type-checking was enabled and then an incremental
    build was performed. This breaks a TypeScript invariant - ts.Programs can
    only be reused once.
    
    The creation of the template type-checking program reuses the main program,
    rendering it moot. Then, on the next incremental build the main program
    would be subject to reuse again, which would crash inside TypeScript.
    
    This commit fixes the issue by reusing the template type-checking program
    from the previous run on the next incremental build. Since under normal
    circumstances the files in the type-checking program aren't changed, this
    should be just as fast.
    
    Testing strategy: a test is added in the incremental_spec which validates
    that program reuse with type-checking turned on does not crash the compiler.
    
    Fixes #30079
    
    PR Close #30090
Commits on Apr 23, 2019
  1. feat(compiler-cli): lower some exported expressions (#30038)

    alxhub authored and benlesh committed Apr 22, 2019
    The compiler uses metadata to represent what it statically knows about
    various expressions in a program. Occasionally, expressions in the program
    for which metadata is extracted may contain sub-expressions which are not
    representable in metadata. One such construct is an arrow function.
    
    The compiler does not always need to understand such expressions completely.
    For example, for a provider defined with `useValue`, the compiler does not
    need to understand the value at all, only the outer provider definition. In
    this case, the compiler employs a technique known as "expression lowering",
    where it rewrites the provider expression into one that can be represented
    in metadata. Chiefly, this involves extracting out the dynamic part (the
    `useValue` expression) into an exported constant.
    
    Lowering is applied through a heuristic, which considers the containing
    statement as well as the field name of the expression.
    
    Previously, this heuristic was not completely accurate in the case of
    route definitions and the `loadChildren` field, which is lowered. If the
    route definition using `loadChildren` existed inside a decorator invocation,
    lowering was performed correctly. However, if it existed inside a standalone
    variable declaration with an export keyword, the heuristic would conclude
    that lowering was unnecessary. For ordinary providers this is true; however
    the compiler attempts to fully understand the ROUTES token and thus even if
    an array of routes is declared in an exported variable, any `loadChildren`
    expressions within still need to be lowered.
    
    This commit enables lowering of already exported variables under a limited
    set of conditions (where the initializer expression is of a specific form).
    This should enable the use of `loadChildren` in route definitions.
    
    PR Close #30038
Commits on Apr 19, 2019
  1. feat(ivy): introduce a flag to control template type-checking for Ivy (

    alxhub authored and benlesh committed Apr 2, 2019
    …#29698)
    
    Template type-checking is enabled by default in the View Engine compiler.
    The feature in Ivy is not quite ready for this yet, so this flag will
    temporarily control whether templates are type-checked in ngtsc.
    
    The goal is to remove this flag after rolling out template type-checking in
    google3 in Ivy mode, and making sure the feature is as compatible with the
    View Engine implementation as possible.
    
    Initially, the default value of the flag will leave checking disabled.
    
    PR Close #29698
  2. feat(ivy): support $any when type-checking templates (#29698)

    alxhub authored and benlesh committed Apr 4, 2019
    This commit adds support in the template type-checking engine for the $any
    cast operation.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  3. fix(ivy): match microsyntax template directives correctly (#29698)

    alxhub authored and benlesh committed Apr 4, 2019
    Previously, Template.templateAttrs was introduced to capture attribute
    bindings which originated from microsyntax (e.g. bindings in *ngFor="...").
    This means that a Template node can have two different structures, depending
    on whether it originated from microsyntax or from a literal <ng-template>.
    
    In the literal case, the node behaves much like an Element node, it has
    attributes, inputs, and outputs which determine which directives apply.
    In the microsyntax case, though, only the templateAttrs should be used
    to determine which directives apply.
    
    Previously, both the t2_binder and the TemplateDefinitionBuilder were using
    the wrong set of attributes to match directives - combining the attributes,
    inputs, outputs, and templateAttrs of the Template node regardless of its
    origin. In the TDB's case this wasn't a problem, since the TDB collects a
    global Set of directives used in the template, so it didn't matter whether
    the directive was also recognized on the <ng-template>. t2_binder's API
    distinguishes between directives on specific nodes, though, so it's more
    sensitive to mismatching.
    
    In particular, this showed up as an assertion failure in template type-
    checking in certain cases, when a directive was accidentally matched on
    a microsyntax template element and also had a binding which referenced a
    variable declared in the microsyntax. This resulted in the type-checker
    attempting to generate a reference to a variable that didn't exist in that
    scope.
    
    The fix is to distinguish between the two cases and select the appropriate
    set of attributes to match on accordingly.
    
    Testing strategy: tested in the t2_binder tests.
    
    PR Close #29698
  4. feat(ivy): support for template type-checking pipe bindings (#29698)

    alxhub authored and benlesh committed Apr 2, 2019
    This commit adds support for template type-checking a pipe binding which
    previously was not handled by the type-checking engine. In compatibility
    mode, the arguments to transform() are not checked and the type returned
    by a pipe is 'any'. In full type-checking mode, the transform() method's
    type signature is used to check the pipe usage and infer the return type
    of the pipe.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  5. perf(ivy): template type-check the entire program in 1 file if possib…

    alxhub authored and benlesh committed Apr 2, 2019
    …le (#29698)
    
    The template type-checking engine previously would assemble a type-checking
    program by inserting Type Check Blocks (TCBs) into existing user files. This
    approach proved expensive, as TypeScript has to re-parse and re-type-check
    those files when processing the type-checking program.
    
    Instead, a far more performant approach is to augment the program with a
    single type-checking file, into which all TCBs are generated. Additionally,
    type constructors are also inlined into this file.
    
    This is not always possible - both TCBs and type constructors can sometimes
    require inlining into user code, particularly if bound generic type
    parameters are present, so the approach taken is actually a hybrid. These
    operations are inlined if necessary, but are otherwise generated in a single
    file.
    
    It is critically important that the original program also include an empty
    version of the type-checking file, otherwise the shape of the two programs
    will be different and TypeScript will throw away all the old program
    information. This leads to a painfully slow type checking pass, on the same
    order as the original program creation. A shim to generate this file in the
    original program is therefore added.
    
    Testing strategy: this commit is largely a refactor with no externally
    observable behavioral differences, and thus no tests are needed.
    
    PR Close #29698
  6. feat(ivy): logical not and safe navigation operation handling in TCBs (

    alxhub authored and benlesh committed Apr 2, 2019
    …#29698)
    
    This commit adds support in the template type-checking engine for handling
    the logical not operation and the safe navigation operation.
    
    Safe navigation in particular is tricky, as the View Engine implementation
    has a rather inconvenient flaw. View Engine checks a safe navigation
    operation `a?.b` as:
    
    ```typescript
    (a != null ? a!.b : null as any)
    ```
    
    The type of this expression is always 'any', as the false branch of the
    ternary has type 'any'. Thus, using null-safe navigation throws away the
    type of the result, and breaks type-checking for the rest of the expression.
    
    A flag is introduced in the type-checking configuration to allow Ivy to
    mimic this behavior when needed.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  7. feat(ivy): add backwards compatibility config to template type-checki…

    alxhub authored and benlesh committed Mar 22, 2019
    …ng (#29698)
    
    View Engine's implementation of naive template type-checking is less
    advanced than the current Ivy implementation. As a result, Ivy catches lots
    of typing bugs which VE does not. As a result, it's necessary to tone down
    the Ivy template type-checker in the default case.
    
    This commit introduces a mechanism for doing that, by passing a config to
    the template type-checking engine. Through this configuration, particular
    checks can be loosened or disabled entirely.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  8. fix(ivy): include directive base class metadata when generating TCBs (#…

    alxhub authored and benlesh committed Apr 1, 2019
    …29698)
    
    Previously the template type-checking code only considered the metadata of
    directive classes actually referenced in the template. If those directives
    had base classes, any inputs/outputs/etc of the base classes were not
    tracked when generating the TCB. This resulted in bindings to those inputs
    being incorrectly attributed to the host component or element.
    
    This commit uses the new metadata package to follow directive inheritance
    chains and use the full metadata for a directive for TCB generation.
    
    Testing strategy: Template type-checking tests included.
    
    PR Close #29698
  9. refactor(ivy): move metadata registration to its own package (#29698)

    alxhub authored and benlesh committed Mar 26, 2019
    Previously, metadata registration (the recording of collected metadata
    during analysis of directives, pipes, and NgModules) was only used to
    produce the `LocalModuleScope`, and thus was handled by the
    `LocalModuleScopeRegistry`.
    
    However, the template type-checker also needs information about registered
    directives, outside of the NgModule scope determinations. Rather than
    reuse the scope registry for an unintended purpose, this commit introduces
    new abstractions for metadata registration and lookups in a separate
    'metadata' package, which the scope registry implements.
    
    This paves the way for a future commit to make use of this metadata for the
    template type-checking system.
    
    Testing strategy: this commit is a refactoring which introduces no new
    functionality, so existing tests are sufficient.
    
    PR Close #29698
  10. fix(ivy): check [class] and [style] bindings properly (#29698)

    alxhub authored and benlesh committed Mar 26, 2019
    Previously, bindings to [class] and [style] were treated like any other
    property binding. That is, they would result in type-checking code that
    attempted to write directly to .class or .style on the element node.
    
    This is incorrect, however - the mapping from Angular's [class] and [style]
    onto the DOM properties is non-trivial.
    
    For now, this commit avoids the issue by only checking the expressions
    themselves and not the assignment to the element properties.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  11. feat(ivy): template type-checking for '#' references in templates (#2…

    alxhub authored and benlesh committed Apr 1, 2019
    …9698)
    
    Previously the template type-checking engine processed templates in a linear
    manner, and could not handle '#' references within a template. One reason
    for this is that '#' references are non-linear - a reference can be used
    before its declaration. Consider the template:
    
    ```html
    {{ref.value}}
    <input #ref>
    ```
    
    Accommodating this required refactoring the type-checking code generator to
    be able to produce Type Check Block (TCB) code non-linearly. Now, each
    template is processed and a list of TCB operations (`TcbOp`s) are created.
    Non-linearity is modeled via dependencies between operations, with the
    appropriate protection in place for circular dependencies.
    
    Testing strategy: TCB tests included.
    
    PR Close #29698
  12. feat(ivy): type-checking for some previously unsupported expressions (#…

    alxhub authored and benlesh committed Mar 23, 2019
    …29698)
    
    This commit adds support for the generation of type-checking expressions for
    forms which were previously unsupported:
    
    * array literals
    * map literals
    * keyed property accesses
    * non-null assertions
    
    Testing strategy: TCB tests included.
    
    Fixes #29327
    FW-1218 #resolve
    
    PR Close #29698
  13. test(ivy): add tests for type_check_block.ts (#29698)

    alxhub authored and benlesh committed Apr 3, 2019
    This commit adds a test suite for the Type Check Block generation which
    doesn't require running the entire compiler (specifically, it doesn't even
    require the creation of a ts.Program).
    
    PR Close #29698
  14. feat(ivy): register NgModules with ids when compiled with AOT (#29980)

    alxhub authored and benlesh committed Apr 18, 2019
    This commit adds registration of AOT compiled NgModules that have 'id'
    properties set in their metadata. Such modules have a call to
    registerNgModuleType() emitted as part of compilation.
    
    The JIT behavior of this code is already in place.
    
    This is required for module loading systems (such as g3) which rely on
    getModuleFactory().
    
    PR Close #29980
  15. test(ivy): replace ɵ with escape code (#29980)

    alxhub authored and benlesh committed Apr 19, 2019
    PR Close #29980
Commits on Apr 16, 2019
  1. release: cut the v8.0.0-beta.13 release

    alxhub committed Apr 16, 2019
Commits on Apr 15, 2019
  1. Revert "feat(ivy): use i18n locale data to determine the plural form …

    alxhub committed Apr 15, 2019
    …of ICU expressions (#29249)" (#29918)
    
    This reverts commit 6a8cca7.
    
    PR Close #29918
Commits on Apr 13, 2019
  1. release: cut the v8.0.0-beta.12 release

    alxhub committed Apr 13, 2019
  2. docs: release notes for the v7.2.13 release

    alxhub committed Apr 13, 2019
Commits on Apr 12, 2019
  1. fix(ivy): use existing 'goog' declaration for goog.getMsg check (#29873)

    alxhub committed Apr 12, 2019
    Previously, this check was done with bracket property access on the
    global object: global['goog']
    
    This will not be minified when Closure compiles this code, which:
    
    1) breaks, because 'goog' will have been minified but the check won't have
       taken that into consideration
    
    2) causes build failures in g3, because the actual property 'goog' is
       forbidden in some published JS code (to ensure obfuscation).
    
    A TODO is added to validate that this logic is correct, as it's difficult to
    test within the Angular repo.
    
    PR Close #29873
  2. build: update @angular/cli version to 8.0.0-beta.13 (#29873)

    alxhub committed Apr 12, 2019
    This commit updates the version of @angular/cli to the recently pushed
    8.0.0-beta.13. This is necessary as the CI has started to fail with a
    module hoisting issue caused by a relative import in the CLI, which is
    fixed in the latest (emergency) release.
    
    PR Close #29873
Commits on Apr 11, 2019
  1. refactor(ivy): use ɵɵ instead of Δ for now (#29850)

    alxhub committed Apr 11, 2019
    The `Δ` caused issue with other infrastructure, and we are temporarily
    changing it to `ɵɵ`.
    
    This commit also patches ts_api_guardian_test and AIO to understand `ɵɵ`.
    
    PR Close #29850
Commits on Apr 1, 2019
  1. perf(ivy): basic incremental compilation for ngtsc (#29380)

    alxhub authored and jasonaden committed Mar 18, 2019
    This commit introduces a mechanism for incremental compilation to the ngtsc
    compiler.
    
    Previously, incremental information was used in the construction of the
    ts.Program for subsequent compilations, but was not used in ngtsc itself.
    
    This commit adds an IncrementalState class, which tracks state between ngtsc
    compilations. Currently, this supports skipping the TypeScript emit step
    when the compiler can prove the contents of emit have not changed.
    
    This is implemented for @Injectables as well as for files which don't
    contain any Angular decorated types. These are the only files which can be
    proven to be safe today.
    
    See ngtsc/incremental/README.md for more details.
    
    PR Close #29380
  2. test(ivy): support multiple compilations in the ngtsc test env (#29380)

    alxhub authored and jasonaden committed Mar 18, 2019
    This commit adds support for compiling the same program repeatedly in a way
    that's similar to how incremental builds work in a tool such as the CLI.
    
    * support is added to the compiler entrypoint for reuse of the Program
      object between compilations. This is the basis of the compiler's
      incremental compilation model.
    
    * support is added to wrap the CompilerHost the compiler creates and cache
      ts.SourceFiles in between compilations.
    
    * support is added to track when files are emitted, for assertion purposes.
    
    * an 'exclude' section is added to the base tsconfig to prevent .d.ts
      outputs from the first compilation from becoming inputs to any subsequent
      compilations.
    
    PR Close #29380
  3. feat(ivy): performance trace mechanism for ngtsc (#29380)

    alxhub authored and jasonaden committed Mar 18, 2019
    This commit adds a `tracePerformance` option for tsconfig.json. When
    specified, it causes a JSON file with timing information from the ngtsc
    compiler to be emitted at the specified path.
    
    This tracing system is used to instrument the analysis/emit phases of
    compilation, and will be useful in debugging future integration work with
    @angular/cli.
    
    See ngtsc/perf/README.md for more details.
    
    PR Close #29380
  4. fix(ivy): avoid remote scoping if it's not actually required (#29404)

    alxhub authored and jasonaden committed Mar 19, 2019
    Currently, ngtsc decides to use remote scoping if the compilation of a
    component may create a cyclic import. This happens if there are two
    components in a scope (say, A and B) and A directly uses B. During
    compilation of B ngtsc will then note that if B were to use A, a cycle would
    be generated, and so it will opt to use remote scoping for B.
    
    ngtsc already uses the R3TargetBinder to correctly track the imports that
    are actually required, for future cycle tracking. This commit expands that
    usage to not trigger remote scoping unless B actually does consume A in its
    template.
    
    PR Close #29404
Commits on Mar 28, 2019
  1. fix(ivy): fix proliferation of provider overrides for modules (#29571)

    alxhub authored and kara committed Mar 28, 2019
    When an @NgModule is imported more than once in the testing module (for
    example it appears in the imports of more than one module, or if it's
    literally listed multiple times), then TestBed had a bug where the
    providers for the module would be overridden many times.
    
    This alone was problematic but would not break tests. However, the original
    value of the providers field of the ngInjectorDef was saved each time, and
    restored in the same order. Thus, if the provider array was [X], and
    overrides were applied twice, then the override array would become
    [X, X'] and then [X, X', X, X']. However, on the second override the state
    [X, X'] would be stored as original. The array would then be restored to
    [X] and then [X, X'].
    
    Each test, therefore, would continue to double the size of the providers
    array for the module, eventually exhausting the browser's memory.
    
    This commit adds a Set to track when overrides have been applied to a module
    and refrain from applying them more than once.
    
    PR Close #29571
Commits on Mar 21, 2019
  1. build(compiler-cli): enable full TypeScript strictness (#29436)

    alxhub authored and matsko committed Mar 21, 2019
    This commit enables strict: true in TypeScript builds of
    //packages/compiler-cli.
    
    PR Close #29436
Commits on Mar 19, 2019
  1. fix(ivy): don't track identifiers of ffr-resolved references (#29387)

    alxhub authored and matsko committed Mar 18, 2019
    This fix is for a bug in the ngtsc PartialEvaluator, which statically
    evaluates expressions.
    
    Sometimes, evaluating a reference requires resolving a function which is
    declared in another module, and thus no function body is available. To
    support this case, the PartialEvaluator has the concept of a foreign
    function resolver.
    
    This allows the interpretation of expressions like:
    
    const router = RouterModule.forRoot([]);
    
    even though the definition of the 'forRoot' function has no body. In
    ngtsc today, this will be resolved to a Reference to RouterModule itself,
    via the ModuleWithProviders foreign function resolver.
    
    However, the PartialEvaluator also associates any Identifiers in the path
    of this resolution with the Reference. This is done so that if the user
    writes
    
    const x = imported.y;
    
    'x' can be generated as a local identifier instead of adding an import for
    'y'.
    
    This was at the heart of a bug. In the above case with 'router', the
    PartialEvaluator added the identifier 'router' to the Reference generated
    (through FFR) to RouterModule.
    
    This is not correct. References that result from FFR expressions may not
    have the same value at runtime as they do at compile time (indeed, this is
    not the case for ModuleWithProviders). The Reference generated via FFR is
    "synthetic" in the sense that it's constructed based on a useful
    interpretation of the code, not an accurate representation of the runtime
    value. Therefore, it may not be legal to refer to the Reference via the
    'router' identifier.
    
    This commit adds the ability to mark such a Reference as 'synthetic', which
    allows the PartialEvaluator to not add the 'router' identifier down the
    line. Tests are included for both the PartialEvaluator itself as well as the
    resultant buggy behavior in ngtsc overall.
    
    PR Close #29387
Commits on Mar 13, 2019
  1. fix(ivy): properly compile NgModules with forward referenced types (#…

    alxhub authored and kara committed Mar 9, 2019
    …29198)
    
    Previously, ngtsc would resolve forward references while evaluating the
    bootstrap, declaration, imports, and exports fields of NgModule types.
    However, when generating the resulting ngModuleDef, the forward nature of
    these references was not taken into consideration, and so the generated JS
    code would incorrectly reference types not yet declared.
    
    This commit fixes this issue by introducing function closures in the
    NgModuleDef type, similarly to how NgComponentDef uses them for forward
    declarations of its directives and pipes arrays. ngtsc will then generate
    closures when required, and the runtime will unwrap them if present.
    
    PR Close #29198
Older
You can’t perform that action at this time.