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
Originally, the ivy_switch mechanism used Bazel genrules to conditionally
compile one TS file or another depending on whether ngc or ngtsc was the
selected compiler. This was done because we wanted to avoid importing
certain modules (and thus pulling them into the build) if Ivy was on or
off. This mechanism had a major drawback: ivy_switch became a bottleneck
in the import graph, as it both imports from many places in the codebase
and is imported by many modules in the codebase. This frequently resulted
in cyclic imports which caused issues both with TS and Closure compilation.
It turns out ngcc needs both code paths in the bundle to perform the switch
during its operation anyway, so import switching was later abandoned. This
means that there's no real reason why the ivy_switch mechanism needed to
operate at the Bazel level, and for the ivy_switch file to be a bottleneck.
This commit removes the Bazel-level ivy_switch mechanism, and introduces
an additional TypeScript transform in ngtsc (and the pass-through tsc
compiler used for testing JIT) to perform the same operation that ngcc
does, and flip the switch during ngtsc compilation. This allows the
ivy_switch file to be removed, and the individual switches to be located
directly next to their consumers in the codebase, greatly mitigating the
circular import issues and making the mechanism much easier to use.
As part of this commit, the tag for marking switched variables was changed
from __PRE_NGCC__ to __PRE_R3__, since it's no longer just ngcc which
flips these tags. Most variables were renamed from R3_* to SWITCH_* as well,
since they're referenced mostly in render2 code.
Test strategy: existing test coverage is more than sufficient - if this
didn't work correctly it would break the hello world and todo apps.
PR Close#26550
This commit also removes the extra jasminewd2 typings, since the changes
have been merged in the official typings with
DefinitelyTyped/DefinitelyTyped#28957.
PR Close#26139
`ngcc` adds marker files to each folder that has been
compiled, containing the version of the ngcc used.
When compiling, it will ignore folders that contain these
marker files, as long as the version matches.
PR Close#25557
When using ViewEncapsulation.ShadowDom, Angular will not remove the child nodes of the DOM node a root Component is bootstrapped into. This enables developers building Angular Elements to use the `<slot>` element to do native content projection.
PR Close#24861
This commit adds an integration test for ngcc, which runs ngcc
against most @angular packages. It does not yet make any assertions
on the result.
PR Close#25406
This change turns on preserve-symlinks in nodejs to verify hermeticity of the Angular build.
BREAKING CHANGE: Use of @angular/bazel rules now requires calling ng_setup_workspace() in your WORKSPACE file.
For example:
local_repository(
name = "angular",
path = "node_modules/@angular/bazel",
)
load("@angular//:index.bzl", "ng_setup_workspace")
ng_setup_workspace()
PR Close#24881
With these changes, the types are a little stricter now and also not
compatible with Protractor's jasmine-like syntax. So, we have to also
use `@types/jasminewd2` for e2e tests (but not for non-e2e tests).
I also had to "augment" `@types/jasminewd2`, because the latest
typings from [DefinitelyTyped][1] do not reflect the fact that the
`jasminewd2` version (v2.1.0) currently used by Protractor supports
passing a `done` callback to a spec.
[1]: 566e039485/types/jasminewd2/index.d.ts (L9-L15)Fixes#23952Closes#24733
PR Close#19904
This uses a new script and CircleCI job called "build-packages-dist"
which shims the new Bazel build to produce outputs matching the legacy
build. We'll use this to get AIO testing onto CircleCI as well.
We move the integration tests to a new circleCI job that depends on this
one, as well as the build publishing job.
Note that every PR will have a trivial green publishing status, because
we always create this job even for PRs. We'd rather not - see
https://discuss.circleci.com/t/workflows-pull-request-filter/14396/4
PR Close#23512
Also switch our CircleCI commands to just
bazel build //...
bazel test //...
as this is easier to understand.
Note, the reason this commit removes `firebase-tools` is:
1) firebase-tools has an optional dependency on
https://www.npmjs.com/package/@google-cloud/functions-emulator
2) yarn's `--ignore-optional` doesn't work for transitive deps, so
there's no way to yarn install without getting that functions-emulator
package
3) functions-emulator has a transitive dep on `grpc`
4) the version of `grpc` we get has `BUILD` files and no `WORKSPACE`
file so it always breaks `bazel build ...`
It could be solved by any of:
1) remove firebase-tools - this is what I did
2) fix yarn so you can omit optional deps of a transitive dep
3) make functions-emulator depend transitively on a more recent `grpc`
version
4) patch `grpc` after install by doing an `rm` command in our
postinstall or something
In its place we must install protobufjs. This is needed by the
ngc-wrapped test, which needs jasmine as well as bazel's worker mode
dependencies, and therefore cannot simply rely on
node_modules =
"@build_bazel_rules_typescript_tsc_wrapped_deps//:node_modules"
PR Close#22168
This adds compilation of @NgModule providers and imports into
ngInjectorDef statements in generated code. All @NgModule annotations
will be compiled and the @NgModule decorators removed from the
resultant js output.
All @Injectables will also be compiled in Ivy mode, and the decorator
removed.
PR Close#22458
Angular Package Format v6 stops bundling files in the esm5 and esm2015
directories, now that Webpack 4 can tree-shake per-file.
Adds some missing files like package.json to make packages closer to
what we publish today.
Refactor ng_package to be a type of npm_package and re-use the packaging
action from that rule.
PR Close#22782
Rename @Injectable({scope -> providedIn}).
Instead of {providedIn: APP_ROOT_SCOPE}, accept {providedIn: 'root'}.
Also, {providedIn: null} implies the injectable should not be added
to any scope.
PR Close#22655
This produces a directory following the Angular Package layout spec.
Includes integration test coverage by making a minimal ng_package in integration/bazel.
Unit tests verify the content of the @angular/core and @angular/common packages.
This doesn't totally match our current output, but is good enough to unblock some
early adopters.
It re-uses logic from the rollup_bundle rule in rules_nodejs. It should also
eventually have the .pack and .publish secondary targets like npm_package rule.
PR Close#22221
It's currently broken on CircleCI because of a TLS change made by GitHub.
This is okay as a permanent change, we don't really want bazel to fetch a full git history.
Fixes#22405
PR Close#22406
InjectionToken can be created with an ngInjectableDef, and previously
this allowed the full expressiveness of @Injectable. However, this
requires a runtime reflection system in order to generate factories
from expressed provider declarations.
Instead, this change requires scoped InjectionTokens to provide the
factory directly (likely using inject() for the arguments), bypassing
the need for a reflection system.
Fixes#22205
PR Close#22207
This commit bundles 3 important changes, with the goal of enabling tree-shaking
of services which are never injected. Ordinarily, this tree-shaking is prevented
by the existence of a hard dependency on the service by the module in which it
is declared.
Firstly, @Injectable() is modified to accept a 'scope' parameter, which points
to an @NgModule(). This reverses the dependency edge, permitting the module to
not depend on the service which it "provides".
Secondly, the runtime is modified to understand the new relationship created
above. When a module receives a request to inject a token, and cannot find that
token in its list of providers, it will then look at the token for a special
ngInjectableDef field which indicates which module the token is scoped to. If
that module happens to be in the injector, it will behave as if the token
itself was in the injector to begin with.
Thirdly, the compiler is modified to read the @Injectable() metadata and to
generate the special ngInjectableDef field as part of TS compilation, using the
PartialModules system.
Additionally, this commit adds several unit and integration tests of various
flavors to test this change.
PR Close#22005
Same fix as e70d7a2a7c
This is because the CompilerOptions needs to have directoryExists undefined in order to get the google3 behavior,
so we have to set the property outside the constructor.
Fixes#21872
PR Close#21876
Both Firefox and Safari are vulnerable to XSS if we use an inert document
created via `document.implementation.createHTMLDocument()`.
Now we check for those vulnerabilities and then use a DOMParser or XHR
strategy if needed.
Further the platform-server has its own library for parsing HTML, so we
sniff for that (by checking whether DOMParser exists) and fall back to
the standard strategy.
Thanks to @cure53 for the heads up on this issue.
PR Close#17019
The CLI app is now checked in, rather than generated dynamically with
`ng new`. This loses some assertion power, but gains hermeticity.
It also checks in lock files for all integration tests, avoiding
floating version numbers.
We'll need another place to integration test between changes in
the various repositories - but the angular/angular PR-blocking status
is not the right place to do this.
PR Close#21555
Implement NgOnChangesFeature, ViewContainerRef, TemplateRef,
and the renderEmbeddedTemplate instruction, and wire together the
pieces required for the ngForOf directive to work.
PR Close#21430
Since our version of Chromium is also pinned, a new ChromeDriver (that
drops support for our Chromium version) can cause random (and unrelated
to the corresponding changes) errors on CI.
This commit pins the version of ChromeDriver and it should now be
manually upgraded to a vrsion that is compatible with th currently used
Chromium version.
PR Close#20940
Add enough BUILD files to make it possible to
`bazel build packages/core/test`
Also re-format BUILD.bazel files with Buildifier.
Add a CI lint check that they stay formatted.
PR Close#20768
- update to TypeScript 2.5
- point the 2.4 typings test at the previous typescript version, so we
don't break it accidentally
- widen the peerDeps from Angular packages that depend on TypeScript
- update to latest TypeScript 2.5 compatible Bazel rules
- move .bazelrc to tools/bazel.rc per https://docs.bazel.build/versions/master/best-practices.html#bazelrc
PR Close#20175
With this commit `ngc` is used instead of `tsc-wrapped` for
collecting metadata and tsickle rewriting and `tsc-wrapped`
is removed from the repository.
`@angular/tsc-wrapped@5` is now deprecated and is no longer
used, updated, or maintained as part as of Angular 5.x.x.
`@angular/tsc-wrapped@4` is still maintained and required by
Angular 4.x.x and will be maintained as long as 4.x.x is in
LTS.
PR Close#19298
previously we relied on yarn creating a new project/package.json in the current dirrectory,
which is incorrect. this change inits the project before installing the cli.
PR Close#19297
We now create 2 programs with exactly the same fileNames and
exactly the same `import` / `export` declarations,
allowing TS to reuse the structure of first program
completely. When passing in an oldProgram and the files didn’t change,
TS can also reuse the old program completely.
This is possible buy adding generated files to TS
in `host.geSourceFile` via `ts.SourceFile.referencedFiles`.
This commit also:
- has a minor side effect on how we generate shared stylesheets:
- previously every import in a stylesheet would generate a new
`.ngstyles.ts` file.
- now, we only generate 1 `.ngstyles.ts` file per entry in `@Component.styleUrls`.
This was required as we need to be able to determine the program files
without loading the resources (which can be async).
- makes all angular related methods in `CompilerHost`
optional, allowing to just use a regular `ts.CompilerHost` as `CompilerHost`.
- simplifies the logic around `Compiler.analyzeNgModules` by introducing `NgAnalyzedFile`.
Perf impact: 1.5s improvement in compiling angular io
PR Close#19275
* Remove now unnecessary portions of build.
* Add a compilePackageES5 method to build ES5 from sources
* Rework all package.json and rollup config files to new format
* Remove "extends" from tsconfig-build.json files and fixup compilation roots
PR Close#18541
Keen Yee Liau
Keen Yee Liau
Kara Erickson
Andrew Kushnir
Brandon Roberts
Martin Mädler
Jason Aden
Paul Gschwendtner
Filipe Silva
Greg Magolan
Alex Rickabaugh
Ben Lesh
Alan Agius
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
Pawel Kozlowski
Rob Wormald
Alex Eagle
Victor Berchet
Lucas Sloan
Olivier Combe
Veres Lajos
Hans Larsen
Chuck Jazdzewski
Martin Probst
David-Emmanuel Divernois
Yuan Gao
Fabian Wiles
Torgeir Helgevold
Igor Minar
Tobias Bosch