We can’t resolve relative urls (e.g. for images) in the compiler as
these urls are meant to be loaded in the browser
(unless we would inline images as base64…).
Also, keep `<link rel=“stylesheet”>` in templates that
reference absolute urls with e.g. `http://`. This
behavior was already present for `@import` rules
within stylesheets.
Closes#4740
Now that we can specify `directives` in either `@View` or `@Component`,
we will try to parse from both.
Previously, we would trash any `directives` parsed in the first
annotation upon encountering the second annotation. This ensures that we
maintain that list of `directives` regardless of annotation ordering.
Handle the situation where a `.dart` file generates a `.ng_meta.json`
file but does not register any reflective information.
An example of this would be a file that defines a const list that looks
like a directive alias. The transformer keeps track of this, and creates
a `.ng_meta.json` file but never creates a `.ng_deps.dart` file, which
can result in other files being linked to it and it not defining an
`initReflector` method.
This splits out `path` and `query` into separate params for `location.go`
and related methods so that we can handle them properly in both `PathLocationStrategy`
and `HashLocationStrategy`.
This handles the problem of not reading query params to populate `Location` on the
initial page load.
Closes#3957Closes#4225Closes#3784
Adds test adapters for TypeScript and JavaScript only, exported
as part of the test_lib module. These work with the Jasmine test
framework, and allow use of the test injector within test blocks
via the `inject` function.
See #4572, #4177, #4035, #2783
This includes the TestComponentBuilder. It allows using the
test injector with Jasmine bindings, and waits for returned
promises before completing async test blocks.
This is useful for the compiler tests, but otherwise it's not useful.
Additionally if an application has external templates (as is common) then
we should actually fetch these templates in tests.
Fixes#4539Closes#4682
This is pretty experimental, but the goal is to track the performance
of our build over time so that we can more easily track perf regressions.
Currently it's integrated only with gulp tasks, but I'd like to expand it
to tracking travis jobs, protractor/benchpress test runs, npm installs, etc.
No PII is being collected. And the data is collected via a Google Analytics
property owned by the Angular team account.
Closes#4672
BREAKING CHANGE
Before
```
<cmp [(prop)]="field"> was desugared to <cmp [prop]="field" (prop)="field=$event">
```
After
```
<cmp [(prop)]="field"> is desugared to <cmp [prop]="field" (prop-change)="field=$event">
```
Closes#4658