* build_bazel_rules_typescript renamed to npm_bazel_typescript
* build_bazel_rules_karma renamed to npm_bazel_karma
* browser_repositories.bzl removed and now using @npm_bazel_karma//:browser_repositories.bzl
* includes some fixes for future ts_library devmode es2015 support but some failure still remain when devmode is es2015 so this PR keeps it as es5 using the bazelOptions.devmodeTargetOverride tsconfig setting
PR Close#28896
This target fails with odd error that we need to investigate:
[01:19:32] I/direct - Using ChromeDriver directly...
[01:19:32] E/direct - Error code: 135
[01:19:32] E/direct - Error message: Could not find chromedriver at /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/external/ngdeps/node_modules/webdriver-manager/selenium/chromedriver_2.41. Run 'webdriver-manager update' to download binaries.
[01:19:32] E/direct - Error: Could not find chromedriver at /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/external/ngdeps/node_modules/webdriver-manager/selenium/chromedriver_2.41. Run 'webdriver-manager update' to download binaries.
PR Close#26735
These tests were previously not running on CI so they have always been broken,
or got broken just recently :-(.
test(ivy): mark failing test targets with fixme-ivy-jit and fixme-ivy-local tags
PR Close#26735
Previously in Ivy, metadata for directives/components/modules/etc was
carried in .d.ts files inside type information encoded on the
DirectiveDef, ComponentDef, NgModuleDef, etc types of Ivy definition
fields. This works well, but has the side effect of complicating Ivy's
runtime code as these extra generic type parameters had to be specified
as <any> throughout the codebase. *DefInternal types were introduced
previously to mitigate this issue, but that's the wrong way to solve
the problem.
This commit returns *Def types to their original form, with no metadata
attached. Instead, new *DefWithMeta types are introduced that alias the
plain definition types and add extra generic parameters. This way the
only code that needs to deal with the extra metadata parameters is the
compiler code that reads and writes them - the existence of this metadata
is transparent to the runtime, as it should be.
PR Close#26203
This change supports compilation of components, directives, and modules
within ngtsc. Support is not complete, but is enough to compile and test
//packages/core/test/bundling/todo in full AOT mode. Code size benefits
are not yet achieved as //packages/core itself does not get compiled, and
some decorators (e.g. @Input) are not stripped, leading to unwanted code
being retained by the tree-shaker. This will be improved in future commits.
PR Close#24427
Ivy definition looks something like this:
```
class MyService {
static ngInjectableDef = defineInjectable({
…
});
}
```
Here the argument to `defineInjectable` is well known public contract which needs
to be honored in backward compatible way between versions. The type of the
return value of `defineInjectable` on the other hand is private and can change
shape drastically between versions without effecting backwards compatibility of
libraries publish to NPM. To our users it is effectively an `OpaqueToken`.
By prefixing the type with `ɵ` we are communicating the the outside world that
the value is not public API and is subject to change without backward compatibility.
PR Close#23371
Adds a stub for `elementStyle` and `elementClass` instruction
with a canonical spec for the compiler. The spec shows the the
compiler should be using `elementStyle` and `elementClass` instruction
in place of `[class]` and `[style]` bindings respectively.
PR Close#22719
This change makes the code cleaner for the user. It does mean
a little bit more work for us since we have to patch the `type` back
into the `DirectiveDef`. However since the patching happens only once
on startup it should not be significant.
PR Close#21374
This separation is no longer needed since directives are now passed into the `container` as an array rather than as child functions of the `containerStart`
PR Close#21374
The rationale of this change is to improve the inter-operability with web
components that might make use of the `<template>` tag.
DEPRECATION
The template tags and template attribute are deprecated:
<template ngFor [ngFor]=items let-item><li>...</li></template>
<li template="ngFor: let item of items">...</li>
should be rewritten as:
<ng-template ngFor [ngFor]=items let-item><li>...</li></ng-template>
Note that they still be supported in 4.x with a deprecartion warning in
development mode.
MIGRATION
- `template` tags (or elements with a `template` attribute) should be rewritten
as a `ng-template` tag,
- `ng-content` selectors should be updated to referto a `ng-template` where they
use to refer to a template: `<ng-content selector="template[attr]">` should be
rewritten as `<ng-content selector="ng-template[attr]">`
- if you consume a component relying on your templates being actual `template`
elements (that is they include a `<ng-content selector="template[attr]">`). You
should still migrate to `ng-template` and make use of `ngProjectAs` to override
the way `ng-content` sees the template:
`<ng-template projectAs="template[attr]">`
- while `template` elements are deprecated in 4.x they continue to work.
