Ivy uses R3Injector, but we are currently pulling in both the StaticInjector
(View Engine injector) and the R3Injector when running with Ivy. This commit
adds an ivy switch so calling Injector.create() pulls in the correct
implementation of the injector depending on whether you are using VE or Ivy.
This saves us about 3KB in the bundle.
PR Close#30219
This PR changes the integration test to load language service the way it would be loaded in the editor.
If the language service is specified in tsconfig, it'd only be loaded for Angular projects.
Specifying it as `globalPlugins` loads it unconditionally whenever tsserver is brought up.
PR Close#30153
This is in preparation for more rigorous testing of external templates, since it'll work differently under the new tsserver plugin model.
PR Close#30128
This PR adds the implementation for `definitionAndBoundSpan` because
it's now preferred over `definition`. vscode would send this new request
for `Go to definition`. As part of this PR the implementation for
`definition` is refactored and simplified. Goldens for both methods are
checked in.
PR Close#30125
We recently had an unexpected size regression in the hello world
tests because the CLI devkit released an RC that regressed us and
the dependencies were not pinned. This change ensures that we only
update dependencies like devkit deliberately, so we do not have
mysterious breakages caused by other packages.
PR Close#30152
Prior to this commit, we were pulling DebugNode and DebugElement
into production builds because BrowserModule automatically pulled
in NgProbe and thus getDebugNode. In Ivy, this is not necessary
because Ivy has its own set of debug utilities. We should use these
existing tools instead of NgProbe.
This commit adds an Ivy switch so we do not pull in NgProbe utilities
when running with Ivy. This saves us ~8KB in prod builds.
PR Close#30130
Master is red due to a size regression that was not caught before. We are making this change to bring master back to green state and will perform further investigation.
PR Close#30134
Currently for Angular Bazel projects, NGC needs to be run in the
"postinstall" NPM script in order to generate required summary files.
We need to update the postinstall `tsconfig` to not check/re-build the
`@angular/core` schematic code which has transitive dependencies
which are only available inside of a CLI project. As this is not guaranteed
to be the case with Angular Bazel projects, we need to make sure that
we don't check/re-build these files.
PR Close#29876
Previous to this commit, providing a component or directive in a test
module without @Injectable() would throw because the injectable factory
would not be found. Providing components in tests in addition to declaring
or importing them is not necessary, but it should not throw an error.
This commit ensures factory data is saved when component defs and directive
defs are created, which allows them to be processed by the module injector.
Note that bootstrapping is still required for this setup to work because
directiveInject() does not support cases where the view has not been
created. This case will be handled in a future commit.
PR Close#29945
The bazel-schematics test could suffer from a version skew where new CLI projects were not yet using a new TS version, but Angular packages already were.
This caused the the `ngc` call in the added `postinstall` to run and fail: https://circleci.com/gh/angular/angular/283109
PR Close#29885
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
The new styling algorithm in angular is designed to evaluate host
bindings stylinh priority in order of directive evaluation order. This,
however, does not work with respect to parent/sub-class directives
because sub-class host bindings are run after the parent host bindings
but still have priority. This patch ensures that the host styling bindings
for parent and sub-class components/directives are executed with respect
to the styling algorithm prioritization.
Jira Issue: FW-1132
PR Close#29602
Prior to this change, a module's imports and exports would be used verbatim
as an injectors' imports. This is detrimental for tree-shaking, as a
module's exports could reference declarations that would then prevent such
declarations from being eligible for tree-shaking.
Since an injector actually only needs NgModule references as its imports,
we may safely filter out any declarations from the list of module exports.
This makes them eligible for tree-shaking once again.
PR Close#29598
Currently our plan is to skip the publish, docgen, and update steps for this package.
During RC, we'll determine if the breaking change is too difficult for users, in which case we might restore the package for another major.
PR Close#29550
* fixes prodmode issue in integration/bazel
BREAKING CHANGE:
@bazel/typescript is now a peerDependency of @angular/bazel so user's of @angular/bazel must add @bazel/typescript to their package.json
PR Close#29508
The API changes are due to enabling strict checks in TypeScript (via `strict: true`).
The payload size changes in `polyfills.js` are due to more browser APIs being patched in recent versions (e.g. `fetch`, `customElement v1`).
PR Close#28219
If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all
the `propertiesToConsider` for that entry-point if we determine that
it does not contain code that was compiled by Angular (for instance it has
no `...metadata.json` file).
The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since
there may be entry-points that are marked despite ngcc not actually compiling anything.
PR Close#29092
You can now specify a list of properties in the package.json that
should be considered (in order) to find the path to the format to compile.
The build marker system has been updated to store the markers in
the package.json rather than an additional external file.
Also instead of tracking the underlying bundle format that was compiled,
it now tracks the package.json property.
BREAKING CHANGE:
The `proertiesToConsider` option replaces the previous `formats` option,
which specified the final bundle format, rather than the property in the
package.json.
If you were using this option to compile only specific bundle formats,
you must now modify your usage to pass in the properties in the package.json
that map to the format that you wish to compile.
In the CLI, the `--formats` is no longer available. Instead use the
`--properties` option.
FW-1120
PR Close#29092
This patch is the first of a few patches which separates the
styling logic between template bindings (e.g. <div [style])
from host bindings (e.g. @HostBinding('style')). This patch
in particular introduces a series of host-specific styling
instructions and changes the existing set of template styling
instructions not to accept directives. The underyling code (which
communicates with the styling algorithm) still works as it did
before.
This PR also separates the styling instruction code into a separate
file and moves over all other instructions into an dedicated
instructions directory.
PR Close#29292
This commit modifies the Bazel builder to copy the Bazel WORKSPACE and
BUILD.bazel files to the project root directory before invoking Bazel.
This hides the Bazel files from users.
PR Close#29110
Fixes the `ngOnDestroy` hook on a component or directive being called twice, if the type is also registered as a provider.
This PR resolves FW-1010.
PR Close#28470
Prior to this fix, both the `NgStyle` and `NgClass` directives made use
of `Renderer2` and this dependency raised issues for future versions of
Angular that cannot inject it. This patch ensures that there are two
versions of both directives: one for the VE and another for Ivy.
Jira Issue: FW-882
PR Close#28711
This commit makes the integration test for bazel-schematics more robust
by removing package.json.replace. Instead of replacing the file, the
test script now just overrides Angular packages with the local ones.
This commit also fixes running the test locally by providing default
argument for CI_CHROMEDRIVER_VERSION_ARG.
PR Close#28872
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
Prior to this fix if a root component was instantiated it create host
bindings, but never render them once update mode ran unless one or more
slot-allocated bindings were issued. Since styling in Ivy does not make
use of LView slots, the host bindings function never ran on the root
component.
This fix ensures that the `hostBindings` function does run for a root
component and also renders the schedlued styling instructions when
executed.
Jira Issue: FW-1062
PR Close#28664
Currently we install `firebase-tools` manually in the
integration tests run script. This is problematic
because it means that we cannot cache `firebase-tools`
properly and Yarn might time out downloading this
dependency. We can safely move this to the top level
`package.json` since Bazel now has a `.bazelignore` and
since we have a cache that works for PRs (with fallback
caching).
Note that the `.bazelignore` is relevant here because
`firebase-tools` has been mainly moved to the bash
script because it broke some Bazel calls.
See 4f0cae0676.
PR Close#28615
There are two ways to bootstrap an Ivy app: with `platformBrowserDynamic().bootstrapModule` and `renderComponent`.
To distinguish between these two approaches we call the `platformBrowserDynamic().bootstrapModule` way `ivy-compat` and the `renderComponent` way just `ivy`.
PR Close#28372
The logic to create additional files needed for Bazel are currently
hosted in `ng new`. Such files include the main.*.ts files needed
for AOT and a different angular.json to use Bazel builder, among others.
This commit refactors the logic into `ng add` so that it can be used to
perform the same modifications in an existing project. Users could do so
by running `ng add @angular/bazel`.
With this change, `ng new` effectively becomes an orchestrator that runs
the original `ng new` followed by `ng add @angular/bazel`.
PR Close#28436
By default, `webdriver-manager update` will download the latest
ChromeDriver version, which might not be compatible with the Chrome
version included in the [docker image used on CI], causing CI failures.
Previously, we used to pin the ChromeDriver version on CI in
[ngcontainer's Dockerfile][2]. This was accidentally broken in #26691,
while moving from ngcontainer to default CircleCI docker images.
This commit fixes the issue by pinning ChromeDriver to a known
compatible version.
[1]: bfd48d156d/.circleci/config.yml (L16)
[2]: bfd48d156d/tools/ngcontainer/Dockerfile (L63)
PR Close#28494
This commit fixes a bug in the Bazel builder in which the path to Bazel
executable is constructed using the project path. For non-default
project, the node_modules directory is actually one level above the
project path.
This PR fixes the bug by resolving node_modules with require.resolve().
It requires @bazel/bazel v0.22.1 because previous versions do not have
index.js or main field in package.json and would cause node module
resolution to fail.
This has been tested with both bazel and ibazel.
PR Close#28478
With the release of @angular/bazel v7.2.3, the npm install step right
after `ng new` installs this version. However there is a bug in the
builder which results in bazel executable not found.
This bug was not discovered before because the dependencies of the
project created by `ng new` are not pinned.
The fix is to pin the version of @angular/bazel to 7.2.2 which relies on
global installation of bazel.
PR Close#28460
yarn install was disabled in ng-new for Bazel schematics because
Bazel manages its own node_modules dependencies and therefore
there is no need to install dependencies twice.
However, the first yarn install is needed for `ng` commands to work,
most notably `ng build`.
This commit restores the original behavior.
PR Close#28381
The current build workflow depends on cross workspace dependency by
installing angular-cli as a Bazel repository. This is not ideal because
it introduces separate node_module directories other than the one
installed by Angular through the yarn_install rule (ngdeps).
This commit removes angular-cli from the Bazel workspace and installs
rollup and @angular-devkit/build-optimizer locally.
PR Close#28215
The current integration test for language service involves piping the
results of one process to another using Unix pipes.
This makes the test hard to debug, and hard to configure.
This commit refactors the integration test to use regular Jasmine
scaffolding.
More importantly, it tests the way the language service will actually
be installed by end users. Users would not have to add
`@angular/language-service` to the plugins section in tsconfig.json
Instead, all they need to do is install the *extension* from
the VS Code Marketplace and Angular Language Service will be loaded
as a global plugin.
PR Close#28168
A few integration tests now depend on @angular/cli.
This commit changes the affected tests to use the dependency
on @angular/cli defined at root package.json.
PR Close#28139
The integration test for bazel-schematics installs Angular in
two different locations:
1. Bazel workspace
2. package.json -> fetched from npm
Pull request #28142 changes the test to always install (1) from
source. This breaks when there's a major version bump since the
versions locally and the version in package.json no longer match.
This change updates package.json to fetch @angular/* packages
locally as well.
PR Close#28194
The current integration test for Bazel schematics downloads a
published version of Angular as required by the http_archive
rule in the CLI created WORKSPACE.
However, this makes the test less useful because it does not
actually test any changes to the Angular repo at source.
This PR replaces the http_archive method in the WORSPACE
with local_repository so that any local changes to the Angular
repo are tested accordingly.
With Typescript 3.2, the file e2e/src/app.po.ts generated by CLI
no longer compiles under Bazel due to missing type annotations.
A temporary file is placed in the integration/bazel-schematics
directory while the change is pending in CLI repo.
https://github.com/angular/angular-cli/pull/13406
PR Close#28061
In ESM5 decorated classes can be indicated by calls to `__decorate()`.
Previously the `ReflectionHost.findDecoratedClasses()` call would identify
helper calls of the form:
```
SomeClass = tslib_1.__decorate(...);
```
But it was missing calls of the form:
```
SomeClass = SomeClass_1 = tslib_1.__decorate(...);
```
This form is common in `@NgModule()` decorations, where the class
being decorated is referenced inside the decorator or another
member.
This commit now ensures that a chain of assignments, of any length,
is now identified as a class decoration if it results in a call to
`__decorate()`.
Fixes#27841
PR Close#27848
A constructor function may have been "synthesized" by TypeScript during
JavaScript emit, in the case no user-defined constructor exists and e.g.
property initializers are used. Those initializers need to be emitted
into a constructor in JavaScript, so the TypeScript compiler generates a
synthetic constructor.
This commit adds identification of such constructors as ngcc needs to be
able to tell if a class did originally have a constructor in the
TypeScript source. When a class has a superclass, a synthesized
constructor must not be considered as a user-defined constructor as that
prevents a base factory call from being created by ngtsc, resulting in a
factory function that does not inject the dependencies of the superclass.
Hence, we identify a default synthesized super call in the constructor
body, according to the structure that TypeScript emits.
PR Close#27897
I'm not sure why this problem is visible only now or how this worked before, but the CI
is now failing because @types/node is missing.
I also added the yarn.lock file which was previously omitted. We want the yarn.lock file in so that
our deps don't change over time without us knowing.
PR Close#27937
The build and test progress logs make the CI log output so long that it
can't be displayed in the UI and one has to download and view the file
locally instead. This makes it harder to get to the interesting lines,
such as error messages.
Similar to #26869, but for the `bazel-schematics` integration project.
PR Close#27934
Updates the app itself to reflect the result of using the `experimentalIvy` flag on the CLI.
The result is similar to:
npx @angular/cli@next new cli-hello-world-ivy --experimental-ivy --defaults
But replaces the current (cli `7.2.0-rc.0`) `renderComponent` bootstrap with the usual `platformBrowserDynamic` one.
It also keeps what the app did (display a pipe, tests it).
PR Close#27797
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360
With that fixed, `ng test` now works.
`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
PR Close#27715
This release of rules_typescript fixes a critical bug: typescript code
was not checked at all, including type-checking, tsetse, and strict deps
fixes#27569
PR Close#27586
BREAKING CHANGES:
Bazel users: rules_angular_dependencies() will no longer install transitive dependencies of build_bazel_rules_nodejs and build_bazel_rules_typescript. User WORKSPACE files will now need to install rules_nodejs and rules_typescript transitive deps directly:
```
load("@build_bazel_rules_typescript//:package.bzl", "rules_typescript_dependencies")
rules_typescript_dependencies()
load("@build_bazel_rules_nodejs//:package.bzl", "rules_nodejs_dependencies")
rules_nodejs_dependencies()
```
PR Close#27264
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
Some engineers were already on Yarn 0.10.x which was permitted by the range in our package.json#engines
However this introduced 'integrity sha512' lines into the yarn.lock files.
Then when engineers use yarn 0.9 (in particular, Bazel did this) then the lock files get tons of meaningless edits.
We could force everyone back to yarn 0.9 but this commit chooses to instead advance everyone past 0.10
PR Close#27193
This integration test was created from a vanilla CLI generated
project with the following modifications:
* remove `PercentPipe` usage from `app.component.html`
- these are not yet supported by ivy
* changed `ng test` in `package.json` to only to `ng build`
- right now we can only confirm that the app will build
* hard-code `ngDevMode` in `index.html`
- the CLI does not yet set this correctly
PR Close#26403
* rename test helper script
* add material to the ngcc integration test
* add MatButton to ngcc integration test checks
* remove platform-server from ngcc integration test
This package does not yet compile as it contains a package-private
(internal) decorated class, which the ngcc compiler does not yet
handle.
PR Close#26403
* No longer depends on a custom CircleCI docker image that comes with Bazel pre-installed. Since Bazel is now available through NPM, we should be able to use the version from `@bazel/bazel` in order to enforce a consistent environment on CI and locally.
* This also reduces the amount of packages that need to be published (ngcontainer is removed)
PR Close#26691
Kara Erickson
Alan
arjunyel
Filipe Silva
Keen Yee Liau
Keen Yee Liau
Andrew Kushnir
Brandon Roberts
Martin Mädler
Jason Aden
Paul Gschwendtner
Greg Magolan
Alex Rickabaugh
Ben Lesh
Matias Niemelä
Pete Bacon Darwin
JoostK
Alex Eagle
JiaLiPassion
Igor Minar
Renovate Bot
George Kalpakas
Marc Laval
Wassim Chegham
Kristiyan Kostadinov
cexbrayat
Miško Hevery
Alex Eagle