Commit Graph

822 Commits

Author SHA1 Message Date
Pete Bacon Darwin 5ad2097be8 fix(ivy): teach template type checker about template attributes (#29041)
For the template type checking to work correctly, it needs to know
what attributes are bound to expressions or directives, which may
require expressions in the template to be evaluated in a different
scope.

In inline templates, there are attributes that are now marked as
"Template" attributes. We need to ensure that the template
type checking code looks at these "bound" attributes as well as the
"input" attributes.

PR Close #29041
2019-03-07 11:27:36 -08:00
Pete Bacon Darwin f535f31d78 fix(ivy): match attribute selectors for content projection with inline-templates (#29041)
The content projection mechanism is static, in that it only looks at the static
template nodes before directives are matched and change detection is run.
When you have a selector-based content projection the selection is based
on nodes that are available in the template.

For example:

```
<ng-content selector="[some-attr]"></ng-content>
```

would match

```
<div some-attr="..."></div>
```

If you have an inline-template in your projected nodes. For example:

```
<div *ngIf="..." some-attr="..."></div>
```

This gets pre-parsed and converted to a canonical form.

For example:

```
<ng-template [ngIf]="...">
  <div some-attr=".."></div>
</ng-template>
```

Note that only structural attributes (e.g. `*ngIf`) stay with the `<ng-template>`
node. The other attributes move to the contained element inside the template.

When this happens in ivy, the ng-template content is removed
from the component template function and is compiled into its own
template function. But this means that the information about the
attributes that were on the content are lost and the projection
selection mechanism is unable to match the original
`<div *ngIf="..." some-attr>`.

This commit adds support for this in ivy. Attributes are separated into three
groups (Bindings, Templates and "other"). For inline-templates the Bindings
and "other" types are hoisted back from the contained node to the `template()`
instruction, so that they can be used in content projection matching.

PR Close #29041
2019-03-07 11:27:36 -08:00
Pete Bacon Darwin 423ac01dcf refactor: rename `AttributeMarker.ProjectOnly` to `AttributeMarker.Bindings` (#29041)
PR Close #29041
2019-03-07 11:27:35 -08:00
Alex Eagle 887faffa25 docs: cleanup contributors (#28930)
- remove individuals from @angular/* package.json, we don't keep them up-to-date
- switch keys in contributors.json to GitHub handles, seems like a better identifier and lets us grab avatar images from GitHub account
- move emeritus ppl to a new Alumni group (won't yet appear on the site)
- add "lead/mentor" keys so we know who is coordinating work
- add a script that generates an "org chart" graphic

PR Close #28930
2019-03-06 14:48:30 -08:00
Andrew Kushnir dc6192c8e5 fix(ivy): properly detect "inputs" and "outputs" field names that should be wrapped in quotes (#29126)
Prior to this change, the RegExp that was used to check for dashes in field names used "g" (global) flag that retains lastIndex, which might result in skipping some fields that should be wrapped in quotes (since lastIndex advanced beyond the next "-" location). This commit removes this flag and updates the test to make sure there are no regressions.

PR Close #29126
2019-03-06 11:01:53 -08:00
Alex Rickabaugh 881807dc36 fix(ivy): never use imported type references as values (#29111)
ngtsc occasionally converts a type reference (such as the type of a
parameter in a constructor) to a value reference (argument to a
directiveInject call). TypeScript has a bad habit of sometimes removing
the import statement associated with this type reference, because it's a
type only import when it initially looks at the file.

A solution to this is to always add an import to refer to a type position
value that's imported, and not rely on the existing import.

PR Close #29111
2019-03-05 16:47:41 -08:00
Marc Laval 25166d4f41 fix(ivy): support property values changed in ngOnChanges (forward rref case) (#29054)
PR Close #29054
2019-03-05 14:27:08 -08:00
Alan b446095c4d refactor: remove unused functions and classes in diagnostics (#28923)
PR Close #28923
2019-03-05 11:40:08 -08:00
Alex Rickabaugh 866d500324 fix(ivy): copy top-level comments into generated factory shims (#29065)
When ngtsc generates a .ngfactory shim, it does so based on the contents of
an original file in the program. Occasionally these original files have
comments at the top which are load-bearing (e.g. they contain jsdoc
annotations which are significant to downstream bundling tools). The
generated factory shims should preserve this comment.

This commit adds a step to the ngfactory generator to preserve the top-level
comment from the original source file.

FW-1006 #resolve
FW-1095 #resolve

PR Close #29065
2019-03-04 15:59:07 -08:00
Andrew Kushnir aa57bdbf90 fix(ivy): wrap "inputs" and "outputs" keys if they contain unsafe characters (#28919)
Prior to this change, keys in "inputs" and "outputs" objects generated by compiler were not checked against unsafe characters. As a result, in some cases the generated code was throwing JS error. Now we check whether a given key contains any unsafe chars and wrap it in quotes if needed.

PR Close #28919
2019-03-04 14:40:42 -08:00
Andrew Kushnir dcafddefb8 fix(ivy): change for-of to forEach for pipes represented with Map (#29068)
This commit fixes the problem with using for-of for pipes represented with Map (by replacing it with forEach operation).

PR Close #29068
2019-03-01 19:00:25 -08:00
Alex Rickabaugh a06824aef6 fix(ivy): correctly evaluate enum references in template expressions (#29062)
The ngtsc partial evaluator previously would not handle an enum reference
inside a template string expression correctly. Enums are resolved to an
`EnumValue` type, which has a `resolved` property with the actual value.

When effectively toString-ing a `ResolvedValue` as part of visiting a
template expression, the partial evaluator needs to translate `EnumValue`s
to their fully resolved value, which this commit does.

PR Close #29062
2019-03-01 15:47:24 -08:00
Alex Rickabaugh b1df9a30f4 fix(ivy): use the imported name of decorators for detection (#29061)
Currently, ngtsc has a bug where if you alias the name of a decorator when
importing it, it won't be detected properly. This is because the compiler
uses the aliased name and not the original, declared name of the decorator
for detection.

This commit fixes the compiler to compare against the declared name of
decorators when available, and adds a test to prevent regression.

PR Close #29061
2019-03-01 15:19:34 -08:00
Alex Rickabaugh 3e5c1bcb9f fix(ivy): track cyclic imports that are added (#29040)
ngtsc has cyclic import detection, to determine when adding an import to a
directive or pipe would create a cycle. However, this detection must also
account for already inserted imports, as it's possible for both directions
of a circular import to be inserted by Ivy (as opposed to at least one of
those edges existing in the user's program).

This commit fixes the circular import detection for components to take into
consideration already added edges. This is difficult for one critical
reason: only edges to files which will *actually* be imported should be
considered. However, that depends on which directives & pipes are used in
a given template, which is currently only known by running the
TemplateDefinitionBuilder during the 'compile' phase. This is too late; the
decision whether to use remote scoping (which consults the import graph) is
made during the 'resolve' phase, before any compilation has taken place.

Thus, the only way to correctly consider synthetic edges is for the compiler
to know exactly which directives & pipes are used in a template during
'resolve'. There are two ways to achieve this:

1) refactor `TemplateDefinitionBuilder` to do its work in two phases, with
directive matching occurring as a separate step which can be performed
earlier.

2) use the `R3TargetBinder` in the 'resolve' phase to independently bind the
template and get information about used directives.

Option 1 is ideal, but option 2 is currently used for practical reasons. The
cost of binding the template can be shared with template-typechecking.

PR Close #29040
2019-03-01 15:18:50 -08:00
Alex Rickabaugh b50283ed67 fix(ivy): support dynamic host attribute bindings (#29033)
In the @Component decorator, the 'host' field is an object which represents
host bindings. The type of this field is complex, but is generally of the
form {[key: string]: string}. Several different kinds of bindings can be
specified, depending on the structure of the key.

For example:

```
@Component({
  host: {'[prop]': 'someExpr'}
})
```

will bind an expression 'someExpr' to the property 'prop'. This is known to
be a property binding because of the square brackets in the binding key.

If the binding key is a plain string (no brackets or parentheses), then it
is known as an attribute binding. In this case, the right-hand side is not
interpreted as an expression, but is instead a constant string.

There is no actual requirement that at build time, these constant strings
are known to the compiler, but this was previously enforced as a side effect
of requiring the binding expressions for property and event bindings to be
statically known (as they need to be parsed). This commit breaks that
relationship and allows the attribute bindings to be dynamic. In the case
that they are dynamic, the references to the dynamic values are reflected
into the Ivy instructions for attribute bindings.

PR Close #29033
2019-03-01 15:18:13 -08:00
Alex Rickabaugh a23a0bc3a4 feat(ivy): support tracking the provenance of DynamicValue (#29033)
DynamicValues are generated whenever a partially evaluated expression is
unable to be resolved statically. They contain a reference to the ts.Node
which wasn't resolvable.

They can also be nested. For example, the expression 'a + b' is resolvable
only if 'a' and 'b' are themselves resolvable. If either 'a' or 'b' resolve
to a DynamicValue, the whole expression must also resolve to a DynamicValue.

Previously, if 'a' resolved to a DynamicValue, the entire expression might
have been resolved to the same DynamicValue. This correctly indicated that
the expression wasn't resolvable, but didn't return a reference to the
shallow node that couldn't be resolved (the expression 'a + b'), only a
reference to the deep node that couldn't be resolved ('a').

In certain situations, it's very useful to know the shallow unresolvable
node (for example, to use it verbatim in the output). To support this,
the partial evaluator is updated to always wrap DynamicValue to point to
each unresolvable expression as it's processed, ensuring the receiver can
determine exactly which expression node failed to resolve.

PR Close #29033
2019-03-01 15:18:13 -08:00
Greg Magolan ea09430039 build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871)
PR Close #28871
2019-02-28 12:06:36 -08:00
Rado Kirov 03d2e5cb1d refactor: Consistently use index access on index signature types. (#28937)
This change helps highlight certain misoptimizations with Closure
compiler. It is also stylistically preferable to consistently use index
access on index sig types.

Roughly, when one sees '.foo' they know it is always checked for typos
in the prop name by the type system (unless 'any'), while "['foo']" is
always not.

Once all angular repos are conforming this will become a tsetse.info
check, enforced by bazel.

PR Close #28937
2019-02-28 02:49:14 -08:00
Andrew Kushnir 772b24ccc3 fix(ivy): avoid missing imports for types that can be represented as values (#28941)
Prior to this change, TypeScript stripped out some imports in case we reference a type that can be represented as a value (for ex. classes). This fix ensures that we use correct symbol identifier, which makes TypeScript retain the necessary import statements.

PR Close #28941
2019-02-27 15:13:40 -08:00
Kristiyan Kostadinov efa10e33a9 fix(ivy): resolve forwardRef when analyzing NgModule (#28942)
Fixes forward refs not being resolved when an NgModule is being analyzed by ngtsc.

This PR resolves FW-1094.

PR Close #28942
2019-02-27 14:02:41 -08:00
Alex Rickabaugh 827e89cfc4 feat(ivy): support inline <style> and <link> tags in components (#28997)
Angular supports using <style> and <link> tags inline in component
templates, but previously such tags were not implemented within the ngtsc
compiler. This commit introduces that support.

FW-1069 #resolve

PR Close #28997
2019-02-27 11:56:40 -08:00
Andrew Kushnir 40833ba54b fix(ivy): process property bindings in i18n blocks similar to non-i18n bindings (#28969)
Prior to this change i18n block bindings were converted to Expressions right away (once we first access them), when in non-i18n cases we processed them differently: the actual conversion happens at instructions generation. Because of this discrepancy, the output for bindings in i18n blocks was generated incorrectly (with invalid indicies in pipeBindN fns and invalid references to non-existent local variables). Now the bindings processing is unified and i18nExp instructions should contain right bind expressions.

PR Close #28969
2019-02-27 11:56:12 -08:00
Alan Agius 34bdebcdd2 feat(ivy): add support for windows concrete types for paths (#28752)
This commit introduces support for the windows paths in the new concrete types mechanism that was introduced in this PR https://github.com/angular/angular/pull/28523

Normalized posix paths that start with either a `/` or `C:/` are considered to be an absolute path.

Note: `C:/` is used as a reference, as other drive letters are also supported.

Fixes #28754

PR Close #28752
2019-02-27 11:27:04 -08:00
Andrew Kushnir 034de06ab1 fix(ivy): avoid duplicate i18n consts to be present in generated output (#28967)
Prior to this change, the logic that outputs i18n consts (like `const MSG_XXX = goog.getMsg(...)`) didn't have a check whether a given const that represent a certain i18n message was already included into the generated output. This commit adds the logic to mark corresponding i18n contexts after translation was generated, to avoid duplicate consts in the output.

PR Close #28967
2019-02-27 10:33:41 -08:00
Alex Rickabaugh d127d05dc3 fix(ivy): correctly resolve shorthand property declarations (#28936)
The partial evaluator in ngtsc can handle a shorthand property declaration
in the middle evaluation, but fails if evaluation starts at the shorthand
property itself. This is because evaluation starts at the ts.Identifier
of the property (the ts.Expression representing it), not the ts.Declaration
for the property.

The fix for this is to detect in TypeScriptReflectionHost when a ts.Symbol
refers to a shorthand property, and to use the ts.TypeChecker method
getShorthandAssignmentValueSymbol() to resolve the value of the assignment
instead.

FW-1089 #resolve

PR Close #28936
2019-02-27 08:48:54 -08:00
Wassim Chegham dad5a258b8 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
Wassim Chegham ce68b4d839 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
Marc Laval 8f8f9a6e61 fix(ivy): ngtsc should correctly bind to context in nested template with many bindings (#28982)
PR Close #28982
2019-02-26 11:54:13 -08:00
Alex Rickabaugh c1392ce618 feat(ivy): produce and consume ES2015 re-exports for NgModule re-exports (#28852)
In certain configurations (such as the g3 repository) which have lots of
small compilation units as well as strict dependency checking on generated
code, ngtsc's default strategy of directly importing directives/pipes into
components will not work. To handle these cases, an additional mode is
introduced, and is enabled when using the FileToModuleHost provided by such
compilation environments.

In this mode, when ngtsc encounters an NgModule which re-exports another
from a different file, it will re-export all the directives it contains at
the ES2015 level. The exports will have a predictable name based on the
FileToModuleHost. For example, if the host says that a directive Foo is
from the 'root/external/foo' module, ngtsc will add:

```
export {Foo as ɵng$root$external$foo$$Foo} from 'root/external/foo';
```

Consumers of the re-exported directive will then import it via this path
instead of directly from root/external/foo, preserving strict dependency
semantics.

PR Close #28852
2019-02-22 12:15:58 -08:00
Alex Rickabaugh 15c065f9a0 refactor(ivy): extract selector scope logic to a new ngtsc package (#28852)
This commit splits apart selector_scope.ts in ngtsc and extracts the logic
into two separate classes, the LocalModuleScopeRegistry and the
DtsModuleScopeResolver. The logic is cleaned up significantly and new tests
are added to verify behavior.

LocalModuleScopeRegistry implements the NgModule semantics for compilation
scopes, and handles NgModules declared in the current compilation unit.
DtsModuleScopeResolver implements simpler logic for export scopes and
handles NgModules declared in .d.ts files.

This is done in preparation for the addition of re-export logic to solve
StrictDeps issues.

PR Close #28852
2019-02-22 12:15:58 -08:00
Kristiyan Kostadinov 32ae84da28 fixup! fix(ivy): incorrectly remapping certain properties that refer to inputs (#28765)
PR Close #28765
2019-02-21 17:59:50 -08:00
Greg Magolan ebffde7143 build: update to rules_typescript 0.25.1 (#28625)
Updated a spot in the compiler which assumed es5 downlevelling get ready for es2015 devmode in the future.

PR Close #28625
2019-02-21 07:46:21 -08:00
Andrew Kushnir 95d9aa22ef fix(ivy): allow HTML comments to be present inside <ng-content> (#28849)
Prior to this change presence of HTML comments inside <ng-content> caused compiler to throw an error that <ng-content> is not empty. Now HTML comments are not considered as a meaningful content, thus no error is thrown. This behavior is now aligned in Ivy/VE.

PR Close #28849
2019-02-21 00:13:40 -08:00
Andrew Kushnir df627e65df fix(ivy): correct absolute path processing for templateUrl and styleUrls (#28789)
Prior to this change absolute file paths (like `/a/b/c/style.css`) were calculated taking current component file location into account. As a result, absolute file paths were calculated using current file as a root. This change updates this logic to ignore current file path in case of absolute paths.

PR Close #28789
2019-02-21 00:13:12 -08:00
Andrew Kushnir 72d043f669 fix(ivy): check the presence of .css resource for styleUrls (#28770)
Prior to this change, Ivy and VE CSS resource resolution was different: in addition to specified styleUrl (with .scss, .less and .styl extensions), VE also makes an attempt to resolve resource with .css extension. This change introduces similar logic for Ivy to make sure Ivy behavior is backwards compatible.

PR Close #28770
2019-02-21 00:12:43 -08:00
Andrew Kushnir be121bba85 fix(ivy): restore @fileoverview annotations for Closure (#28723)
Prior to this change, the @fileoverview annotations added by users in source files or by tsickle during compilation might have change a location due to the fact that Ngtsc may prepend extra imports or constants. As a result, the output file is considered invalid by Closure (misplaced @fileoverview annotation). In order to resolve the problem we relocate @fileoverview annotation if we detect that its host node shifted.

PR Close #28723
2019-02-21 00:12:14 -08:00
Paul Gschwendtner 58436fd81a fix(ivy): unable to import shim factory files on case-insensitive platforms (#28831)
This change is kind of similar to #27466, but instead of ensuring that
these shims can be generated, we also need to make sure that developers
are able to also use the factory shims like with `ngc`.

This issue is now surfacing because we have various old examples which
are now also built with `ngtsc`  (due to the bazel migration). On case insensitive
platforms (e.g. windows) these examples cannot be built because ngtsc fails
the app imports a generated shim file (such as the factory shim files).

This is because the `GeneratedShimsHostWrapper` TypeScript host uses
the `getCanonicalFileName` method in order to check whether a given
file/module exists in the generator file maps. e.g.

```
// Generator Map:
'C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts' =>
'C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ts',

// Path passed into `fileExists`
C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts

// After getCanonicalFileName (notice the **lower-case drive name**)
c:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts
```

As seen above, the generator map does not use the canonical file names, as well as
TypeScript internally does not pass around canonical file names. We can fix this by removing
the manual call to `getCanonicalFileName` and just following TypeScript internal-semantics.

PR Close #28831
2019-02-20 18:26:05 -08:00
Paul Gschwendtner 3336de0970 refactor(ivy): fix typo in ngtsc "listLazyRoutes" method (#28831)
Fixes a minor typo in the `listLazyRoutes` method for `ngtsc`. Also in
addition fixes that a newly introduced test for `listLazyRoutes` broke the
tests in Windows. It's clear that we still don't run tests against
Windows, but we also made all other tests pass (without CI verification),
and it's not a big deal fixing this while being at it.

PR Close #28831
2019-02-20 18:26:05 -08:00
Matias Niemelä d0e81eb593 feat(ivy): open up ivy_switch_mode to non-core packages (#28711)
Prior to this fix, using the compiler's ivy_switch mechanism was
only available to core packages. This patch allows for this variable
switching mechanism to work across all other angular packages.

PR Close #28711
2019-02-20 13:46:14 -08:00
Greg Magolan 25aae64274 build(bazel): do not build rxjs from source under Bazel (#28720)
PR Close #28720
2019-02-19 16:28:14 -08:00
Kara Erickson 3c1a1620e3 fix(ivy): support static ContentChild queries (#28811)
This commit adds support for the `static: true` flag in `ContentChild`
queries. Prior to this commit, all `ContentChild` queries were resolved
after change detection ran. This is a problem for backwards
compatibility because View Engine also supported "static" queries which
would resolve before change detection.

Now if users add a `static: true` option, the query will be resolved in
creation mode (before change detection runs). For example:

```ts
@ContentChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:01 -08:00
Kara Erickson a4638d5a81 fix(ivy): support static ViewChild queries (#28811)
This commit adds support for the `static: true` flag in
`ViewChild` queries. Prior to this commit, all `ViewChild`
queries were resolved after change detection ran. This is
a problem for backwards compatibility because View Engine
also supported "static" queries which would resolve before
change detection.

Now if users add a `static: true` option, the query will be
resolved in creation mode (before change detection runs).
For example:

```ts
@ViewChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:00 -08:00
George Kalpakas 745c9c5ca7 build(compiler-cli): upgrade chokidar to latest version (#28797)
Fixes #28771

PR Close #28797
2019-02-19 12:54:11 -08:00
Paul Gschwendtner 4131715df5 fix(compiler-cli): incorrect bundled metadata for static class member call expressions (#28762)
Currently if developers use call expressions in their static
class members ([like we do in Angular](https://github.com/angular/angular/blob/master/packages/core/src/change_detection/differs/keyvalue_differs.ts#L121)),
the metadata that is generated for flat modules is invalid. This
is because the metadata bundler logic currently does not handle
call expressions in static class members and the symbol references
are not rewritten to avoid relative paths in the bundle.

Static class members using a call expression are not relevant for
the ViewEngine AOT compilation, but it is problematic that the
bundled metadata references modules using their original relative
path. This means that the bundled metadata is no longer encapsulated
and depends on other emitted files to be emitted in the proper place.

These incorrect relative paths can now cause issues where NGC
looks for the referenced symbols in the incorrect path. e.g.

```
src/
 | lib/
    | index.ts -> References the call expression using `../../di`
```

Now the metadata looks like that:

```
node_modules/
  | @angular/
  -- | core/
  -- -- | core.metadata.json -> Says that the call expr. is in `../../di`.
  | di/
```

Now if NGC tries to use the metadata files and create the summary files,
NGC resolves the call expression to the `node_modules/di` module. Since
the "unexpected" module does not contain the desired symbol, NGC will
error out.

We should fix this by ensuring that we don't ship corrupted metadata
to NPM which contains relative references that can cause such
failures (other imports can be affected as well; it depends on what
modules the developer has installed and how we import our call
expressions).

Fixes #28741.

PR Close #28762
2019-02-19 12:53:18 -08:00
Filipe Silva 1923c2f99c feat(compiler-cli): make enableIvy ngtsc/true equivalent (#28616)
Currently setting `enableIvy` to true runs a hybrid mode of `ngc` and `ngtsc`. This is counterintuitive given the name of the flag itself.

This PR makes the `true` value equivalent to the previous `ngtsc`, and `ngtsc` becomes an alias for `true`. Effectively this removes the hybrid mode as well since there's no other way to enable it.

PR Close #28616
2019-02-19 12:28:44 -08:00
George Kalpakas 6b511a33f6 fix(ivy): fix class inheritance detection for ES5 code in `ngtsc` (#28773)
Previously, `ngtsc` detected class inheritance in a way that only worked
in TS or ES2015 code. As a result, inheritance would not be detected for
code in ES5 format, such as when running `ngtsc` through `ngcc` to
transform old-style Angular code to ivy format.

This commit fixes it by delegating class inheritance detection to the
current `ReflectionHost`, which is able to correctly interpret the used
code format.

PR Close #28773
2019-02-16 21:00:50 -08:00
Kristiyan Kostadinov 80a5934af6 fix(ivy): support schemas at runtime (#28637)
Accounts for schemas in when validating properties in Ivy.

This PR resolves FW-819.

A couple of notes:
* I had to rework the test slightly, in order to have it fail when we expect it to. The one in master is passing since Ivy's validation runs during the update phase, rather than creation.
* I had to deviate from the design in FW-819 and not add an `enableSchema` instruction, because the schema is part of the `NgModule` scope, however the scope is only assigned to a component once all of the module's declarations have been resolved and some of them can be async. Instead, I opted to have the `schemas` on the component definition.

PR Close #28637
2019-02-14 19:31:51 +00:00
Paul Gschwendtner 7cbc36fdac build: remove unused rollup.config.js files (#28646)
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.

PR Close #28646
2019-02-14 19:28:08 +00:00
Alex Rickabaugh 423b39e216 feat(ivy): use fileNameToModuleName to emit imports when it's available (#28523)
The ultimate goal of this commit is to make use of fileNameToModuleName to
get the module specifier to use when generating an import, when that API is
available in the CompilerHost that ngtsc is created with.

As part of getting there, the way in which ngtsc tracks references and
generates import module specifiers is refactored considerably. References
are tracked with the Reference class, and previously ngtsc had several
different kinds of Reference. An AbsoluteReference represented a declaration
which needed to be imported via an absolute module specifier tracked in the
AbsoluteReference, and a RelativeReference represented a declaration from
the local program, imported via relative path or referred to directly by
identifier if possible. Thus, how to refer to a particular declaration was
encoded into the Reference type _at the time of creation of the Reference_.

This commit refactors that logic and reduces Reference to a single class
with no subclasses. A Reference represents a node being referenced, plus
context about how the node was located. This context includes a
"bestGuessOwningModule", the compiler's best guess at which absolute
module specifier has defined this reference. For example, if the compiler
arrives at the declaration of CommonModule via an import to @angular/common,
then any references obtained from CommonModule (e.g. NgIf) will also be
considered to be owned by @angular/common.

A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface
are introduced. To produce an Expression referring to a given Reference'd
node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy
implementations.

Several different strategies are defined:

- LocalIdentifierStrategy: use local ts.Identifiers if available.
- AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule,
  import the node via an absolute import from that module specifier.
- LogicalProjectStrategy: if the Reference is in the logical project
  (is under the project rootDirs), import the node via a relative import.
- FileToModuleStrategy: use a FileToModuleHost to generate the module
  specifier by which to import the node.

Depending on the availability of fileNameToModuleName in the CompilerHost,
then, a different collection of these strategies is used for compilation.

PR Close #28523
2019-02-13 19:13:11 -08:00
Alex Rickabaugh a529f53031 feat(ivy): introduce concrete types for paths in ngtsc (#28523)
This commit introduces a new ngtsc sub-library, 'path', which contains
branded string types for the different kind of paths that ngtsc manipulates.
Having static types for these paths will reduce the number of path-related
bugs (especially on Windows) and will eliminate unnecessary defensive
normalizing.

See the README.md file for more detail.

PR Close #28523
2019-02-13 19:13:11 -08:00