Commit Graph

102 Commits

Author SHA1 Message Date
Kristiyan Kostadinov 59ef40988e feat(core): support TypeScript 4.2 (#41158)
Updates the repo to TypeScript 4.2 and tslib 2.1.0.

PR Close #41158
2021-03-17 09:10:25 -07:00
Joey Perrott cbdb5e208e fix(dev-infra): update type castings for JSON.parse usage (#40710)
Update usages of JSON.parse to be cast as specific types.

PR Close #40710
2021-02-09 10:48:43 -08:00
Joey Perrott b8b8535f40 build: update tools directory for latest changes in rules_nodejs (#40710)
Update the scripts/tooling in the tools directory to handle the changes in the latest
version of rules_nodejs.

PR Close #40710
2021-02-09 10:48:43 -08:00
Joey Perrott c9033d6193 build: set the repository information for ts-api-guardian (#40512)
Set the repository information in the package.json for ts-api-guardian to
allow it to be published via wombat proxy.

PR Close #40512
2021-01-21 13:53:08 -08:00
Joey Perrott 0e95460cf8 build: bump ts-api-guardian to 0.5.1 (#40511)
Update to new patch version of the experimental ts-api-guardian package.

PR Close #40511
2021-01-21 12:23:18 -08:00
Joey Perrott 71ea1a6199 build: set up publishing registry for ts-api-guardian (#40511)
Set the ts-api-guardian to be published via the wombot proxy.

PR Close #40511
2021-01-21 12:23:18 -08:00
Alan Agius bd17610c29 feat(dev-infra): make ts-api-guardian compatible with rules_nodejs version 3 (#40353)
Changes include:
- Remove `bazelWorkspaces` as this is no longer supported due to
  a single version policy https://github.com/bazelbuild/rules_nodejs/pull/783
  and `install_bazel_dependencies` has been removed.
- Enable `bazel_patch_module_resolver` since monkey-patch the
   implementation of `require()` in NodeJS is opt-in

More info about the changes can be found here: https://github.com/bazelbuild/rules_nodejs/wiki#migrating-to-30

Blocking: https://github.com/angular/angular-cli/pull/19716

PR Close #40353
2021-01-11 15:36:29 -08:00
Charles Lyding 318255a5f8 build: support building with TypeScript 4.1 (#39571)
TypeScript 4.1 is now used to build and test within the repository.

PR Close #39571
2020-11-25 11:10:01 -08:00
Greg Magolan 42a164f522 build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#39182)
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.

Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0

Features of note for angular/angular:

* stdout/stderr/exit code capture; this could be potentially be useful

* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
  heavy weight

Breaking changes of note for angular/angular:

* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
  (which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`

* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
  no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
  a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.

* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
  require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
  `@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
  load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
  `@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
  internals for ng_module.

* runfiles.resolve will now throw instead of returning undefined to match behavior of node require

Other changes in angular/angular:

* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
  The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
  supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
  that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
  use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
  as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
  example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.

NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.

* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.

PR Close #39182
2020-10-08 11:54:59 -07:00
Joey Perrott c214cad2b4 Revert "build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727)" (#39097)
This reverts commit db56cf18ba.

PR Close #39097
2020-10-02 10:56:53 -07:00
Greg Magolan db56cf18ba build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727)
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.

Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0

Features of note for angular/angular:

* stdout/stderr/exit code capture; this could be potentially be useful

* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
  heavy weight

Breaking changes of note for angular/angular:

* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
  (which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`

* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
  no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
  a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.

* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
  require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
  `@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
  load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
  `@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
  internals for ng_module.

* runfiles.resolve will now throw instead of returning undefined to match behavior of node require

Other changes in angular/angular:

* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
  The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
  supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
  that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
  use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
  as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
  example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
  https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.

NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.

* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
  @josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial.

PR Close #37727
2020-10-01 15:34:36 -07:00
Alan Agius 0fc44e0436 feat(compiler-cli): add support for TypeScript 4.0 (#38076)
With this change we add support for TypeScript 4.0

PR Close #38076
2020-08-24 13:06:59 -07:00
Igor Minar 5d3ba8dec7 test: update ts-api-guardian's strip_export_pattern to exclude Ivy instructions (#38224)
Previously the instructions were included in the golden files to monitor the frequency and rate of
the instruction API changes for the purpose of understanding the stability of this API (as it was
considered for becoming a public API and deployed to npm via generated code).

This experiment has confirmed that the instruction API is not stable enough to be used as public
API. We've since also came up with an alternative plan to compile libraries with the Ivy compiler
for npm deployment and this plan does not rely on making Ivy instructions public.

For these reasons, I'm removing the instructions from the golden files as it's no longer important
to track them.

The are three instructions that are still being included: `ɵɵdefineInjectable`, `ɵɵinject`, and
`ɵɵInjectableDef`.

These instructions are already generated by the VE compiler to support tree-shakable providers, and
code depending on these instructions is already deployed to npm. For this reason we need to treat
them as public api.

This change also reduces the code review overhead, because changes to public api golden files now
require multiple approvals.

PR Close #38224
2020-07-27 14:37:41 -07:00
Alan Agius 6651b4171d build: update to typescript 3.9.5 (#37456)
This TypeScript version contains the revert for the classes wrapped in IIFE change that was introduced in version 3.9.

PR Close #37456
2020-06-11 12:05:33 -07:00
Joey Perrott d1ea1f4c7f build: update license headers to reference Google LLC (#37205)
Update the license headers throughout the repository to reference Google LLC
rather than Google Inc, for the required license headers.

PR Close #37205
2020-05-26 14:26:58 -04:00
Alan Agius 13ba84731f build: prepare for TypeScript 3.9 (#36989)
- Fix several compilation errors
- Update @microsoft/api-extractor to be compatible with TypeScript 3.9

PR Close #36989
2020-05-14 10:50:28 -07:00
Andrew Scott fbd281c26e build: remove typescript 3.6 and 3.7 support (#36329)
Remove TypeScript 3.6 and 3.7 support from Angular along with tests that
ensure those TS versions work.

BREAKING CHANGE: typescript 3.6 and 3.7 are no longer supported, please
update to typescript 3.8

PR Close #36329
2020-05-05 16:52:43 -07:00
Joey Perrott 698b0288be build: reformat repo to new clang@1.4.0 (#36613)
PR Close #36613
2020-04-14 12:08:36 -07:00
Greg Magolan 9e78f55c32 style: typescript lint fix (#36531)
PR Close #36531
2020-04-09 00:59:21 +00:00
Greg Magolan f1731d807e Revert "refactor(bazel): use runfiles helper in ts-api-guardian (#36471)" (#36531)
This reverts commit 92c4f3d508.

PR Close #36531
2020-04-09 00:59:21 +00:00
Greg Magolan 92c4f3d508 refactor(bazel): use runfiles helper in ts-api-guardian (#36471)
Pre-fractor for future rules_nodejs release when require.resolve patches are removed.

PR Close #36471
2020-04-08 15:57:52 -07:00
Paul Gschwendtner a1e00f82f4 build: fix ts-api-guardian golden approval not working on windows (#36115)
Currently on Windows, it's not possible to approve goldens in
`ts-api-guardian`. This is because paths are resolved relatively
to the working directory. In Windows, golden files are resolved
to the actual workspace directory. The current logic tries to
compute a relative path to the runfile from the working directory.

This causes the file paths to have a lot of parent directory
path segments. Eventually, when joined with the build workspace
directory, the paths end up being incorrect. e.g.

```
fileName = ../../../../../../projects/angular/golden/<..>/common.d.ts`
outFile = BUILD_WORKSPACE_DIR + fileName;
```

To fix this, we no longer deal with confusing relative paths, but
instead always use absolute file system paths.

Additionally, this fixes that new goldens are generated at the wrong
location on all platforms.

PR Close #36115
2020-03-17 12:38:25 -07:00
Paul Gschwendtner 34a17f3699 Revert "build: fix ts-api-guardian golden approval not working on windows (#36096)" (#36113)
This reverts commit f862536ec4.

Reverted due to test failures that have shown up in the Windows CI Jobs
that don't run on pull requests. A follow-up will be sent that re-adds
the changes w/ fixes for the windows test job.

PR Close #36113
2020-03-17 11:18:07 -07:00
Paul Gschwendtner f862536ec4 build: fix ts-api-guardian golden approval not working on windows (#36096)
Currently on Windows, it's not possible to approve goldens in
`ts-api-guardian`. This is because paths are resolved relatively
to the working directory. In Windows, golden files are resolved
to the actual workspace directory. The current logic tries to
compute a relative path to the runfile from the working directory.

This causes the file paths to have a lot of parent directory
path segments. Eventually, when joined with the build workspace
directory, the paths end up being incorrect. e.g.

```
fileName = ../../../../../../projects/angular/golden/<..>/common.d.ts`
outFile = BUILD_WORKSPACE_DIR + fileName;
```

To fix this, we no longer deal with confusing relative paths, but
instead always use absolute file system paths.

Additionally, this fixes that new goldens are generated at the wrong
location on all platforms.

PR Close #36096
2020-03-17 10:42:09 -07:00
Alan Agius 2e493edf80 build: provide full paths to `ts_api_guardian_test_npm_package` and `ts_api_guardian_test` (#36034)
ts-api-guardian uses `require.resolve` to resolve the actual and golden files under bazel. In Windows for these files to be resolved correct the full path including the workspace name as per the MANIFEST entries is required.

This used to be the case until the recent changes done to use npm_integration tests

83c74ceacf/tools/public_api_guard/public_api_guard.bzl (L19)
83c74ceacf/tools/public_api_guard/public_api_guard.bzl (L28)

```
bazel test //packages/... --test_tag_filters=api_guard

//packages/animations:animations_api                            (cached) PASSED in 18.4s
//packages/common:common_api                                    (cached) PASSED in 25.5s
//packages/compiler-cli:compiler_options_api                    (cached) PASSED in 12.4s
//packages/compiler-cli:error_code_api                          (cached) PASSED in 11.6s
//packages/core:core_api                                        (cached) PASSED in 20.6s
//packages/core:ng_global_utils_api                             (cached) PASSED in 13.5s
//packages/elements:elements_api                                (cached) PASSED in 11.9s
//packages/forms:forms_api                                      (cached) PASSED in 13.9s
//packages/http:http_api                                        (cached) PASSED in 14.8s
//packages/localize:localize_api                                (cached) PASSED in 6.3s
//packages/platform-browser:platform-browser_api                (cached) PASSED in 18.1s
//packages/platform-browser-dynamic:platform-browser-dynamic_api (cached) PASSED in 14.0s
//packages/platform-server:platform-server_api                  (cached) PASSED in 13.9s
//packages/platform-webworker:platform-webworker_api            (cached) PASSED in 13.7s
//packages/platform-webworker-dynamic:platform-webworker-dynamic_api (cached) PASSED in 11.7s
//packages/router:router_api                                    (cached) PASSED in 19.9s
//packages/service-worker:service-worker_api                    (cached) PASSED in 18.1s
//packages/upgrade:upgrade_api                                  (cached) PASSED in 13.5s
```

Reference: DEV-71

PR Close #36034
2020-03-12 09:49:00 -07:00
Joey Perrott 15f8afa4bf ci: move public-api goldens to goldens directory (#35768)
Moves the public api .d.ts files from tools/public_api_guard to
goldens/public-api.

Additionally, provides a README in the goldens directory and a script
assist in testing the current state of the repo against the goldens as
well as a command for accepting all changes to the goldens in a single
command.

PR Close #35768
2020-03-10 20:58:39 -04:00
Joey Perrott b7519e5cfa build: allow auto-discover all typings files in npm package by ts-api-guardian (#35691)
Adds a new feature to ts-api-guardian allowing for automatically discovering all
entry point d.ts files from all package.json files in a provided directory.

PR Close #35691
2020-02-27 14:02:16 -08:00
Greg Magolan dde68ff954 build: add npm_integration_test && angular_integration_test (#33927)
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as  `BUILD_WORKSPACE_DIRECTORY` will be set in that context

* test //integration:bazel_test and //integration:bazel-schematics_test exclusively

* run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute

```
//integration:bazel-schematics_test                                      PASSED in 317.2s
//integration:bazel_test                                                 PASSED in 167.8s
```

* Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are:
- cli-hello-world*
- hello_world__closure

* add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test

@babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive.

NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0
NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass
NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct.

PR Close #33927
2020-02-24 08:59:18 -08:00
Joey Perrott 3049878aa9 ci: bump release version of ts-api-guardian (#34933)
PR Close #34933
2020-01-23 13:24:53 -08:00
Alan Agius 17e98e1678 build: disable link to PUBLIC_API docs when running ts-api-guardian in angular repo (#34786)
Currently we are showing the following link https://github.com/angular/angular/blob/master/docs/PUBLIC_API.md#golden-files whenever there are updates to the golden files. However this is not correct as this document only applies to the Angular repo as other consumers of ts-api-guardian have different commands, and they store they golden files in different locations.

PR Close #34786
2020-01-21 13:08:47 -05:00
Greg Magolan e0601df59d build: cleanup //tools/ts-api-guardian:tests target (#34736)
PR Close #34736
2020-01-15 14:58:07 -05:00
Greg Magolan dcff76e8b9 refactor: handle breaking changes in rules_nodejs 1.0.0 (#34736)
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.

PR Close #34736
2020-01-15 14:58:07 -05:00
Greg Magolan 93c2df23bf build: upgrade to rules_nodejs 1.0.0 (first stable release) (#34736)
Brings in the fix for stamping which was preventing many targets from getting cached.

PR Close #34736
2020-01-15 14:58:07 -05:00
Andrius 1f79e624d1 build: typescript 3.7 support (#33717)
This PR updates TypeScript version to 3.7 while retaining compatibility with TS3.6.

PR Close #33717
2020-01-14 16:42:21 -08:00
atscott e88d652f2a Revert "build: upgrade to rules_nodejs 1.0.0 (first stable release) (#34589)" (#34730)
This reverts commit cb6ffa1211.

PR Close #34730
2020-01-10 14:12:15 -08:00
atscott 538d0446b5 Revert "refactor: handle breaking changes in rules_nodejs 1.0.0 (#34589)" (#34730)
This reverts commit 9bb349e1c8.

PR Close #34730
2020-01-10 14:12:15 -08:00
atscott 2f810b2c1f Revert "build: cleanup //tools/ts-api-guardian:tests target (#34589)" (#34730)
This reverts commit 7a63e4f7d5.

PR Close #34730
2020-01-10 14:12:14 -08:00
Greg Magolan 7a63e4f7d5 build: cleanup //tools/ts-api-guardian:tests target (#34589)
PR Close #34589
2020-01-10 08:32:00 -08:00
Greg Magolan 9bb349e1c8 refactor: handle breaking changes in rules_nodejs 1.0.0 (#34589)
The major one that affects the angular repo is the removal of the bootstrap attribute in nodejs_binary, nodejs_test and jasmine_node_test in favor of using templated_args --node_options=--require=/path/to/script. The side-effect of this is that the bootstrap script does not get the require.resolve patches with explicitly loading the targets _loader.js file.

PR Close #34589
2020-01-10 08:31:59 -08:00
Greg Magolan cb6ffa1211 build: upgrade to rules_nodejs 1.0.0 (first stable release) (#34589)
Brings in the fix for stamping which was preventing many targets from getting cached.

PR Close #34589
2020-01-10 08:31:58 -08:00
Judy Bogart a00f82797b docs: document golden file requirement (#33900)
PR Close #33900
2020-01-07 10:58:53 -08:00
Alex Rickabaugh bb290cefae fix(core): make QueryList implement Iterable in the type system (#33536)
Originally, QueryList implemented Iterable and provided a Symbol.iterator
on its prototype. This caused issues with tree-shaking, so QueryList was
refactored and the Symbol.iterator added in its constructor instead. As
part of this change, QueryList no longer implemented Iterable directly.

Unfortunately, this meant that QueryList was no longer assignable to
Iterable or, consequently, NgIterable. NgIterable is used for NgFor's input,
so this meant that QueryList was not usable (in a type sense) for NgFor
iteration. View Engine's template type checking would not catch this, but
Ivy's did.

As a fix, this commit adds the declaration (but not the implementation) of
the Symbol.iterator function back to QueryList. This has no runtime effect,
so it doesn't affect tree-shaking of QueryList, but it ensures that
QueryList is assignable to NgIterable and thus usable with NgFor.

Fixes #29842

PR Close #33536
2019-11-19 13:43:53 -08:00
Greg Magolan 4ee354da99 build: switch to @build_bazel_rules_nodejs//:index.bzl load point (#33433)
The defs.bzl load point will be removed for the rules_nodejs 1.0 release.

PR Close #33433
2019-10-28 10:10:48 -07:00
Igor Minar 86e1e6c082 feat: typescript 3.6 support (#32946)
BREAKING CHANGE: typescript 3.4 and 3.5 are no longer supported, please update to typescript 3.6

Fixes #32380

PR Close #32946
2019-10-18 13:15:16 -04:00
Joey Perrott 3a90a7cb43 ci: run ts-api-guardian test remotely on CI (#32677)
PR Close #32677
2019-09-13 15:13:44 -07:00
Igor Minar 6ece7db37a build: TypeScript 3.5 upgrade (#31615)
https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-35

PR Close #31615
2019-07-25 17:05:23 -07:00
Paul Gschwendtner 16ac611a84 build: ts-api-guardian npm package contains invalid references (#31096)
Currently when building the `ts-api-guardian` npm package,
the labels are not properly replaced after recent changes to
the `entry_point` attribute. This means that the `ts-api-guardian`
package is currently not usable externally.

PR Close #31096
2019-06-18 09:50:41 -07:00
Alex Eagle ef0b2cc74d build: convert entry_point to label (#30627)
PR Close #30627
2019-06-11 00:03:11 +00:00
Ben Lesh d7eaae6f22 refactor(ivy): Move instructions back to ɵɵ (#30546)
There is an encoding issue with using delta `Δ`, where the browser will attempt to detect the file encoding if the character set is not explicitly declared on a `<script/>` tag, and Chrome will find the `Δ` character and decide it is window-1252 encoding, which misinterprets the `Δ` character to be some other character that is not a valid JS identifier character

So back to the frog eyes we go.

```
    __
   /ɵɵ\
  ( -- ) - I am ineffable. I am forever.
 _/    \_
/  \  /  \
==  ==  ==
```

PR Close #30546
2019-05-20 16:37:47 -07:00
Ben Lesh cf86ed7b29 refactor(ivy): migrate ɵɵ prefix back to Δ (#30362)
Now that issues are resolved with Closure compiler, we can move back to our desired prefix of `Δ`.

PR Close #30362
2019-05-14 16:52:15 -07:00