2018-08-09 09:23:56 -04:00
#!/bin/bash
2019-09-05 16:45:58 -04:00
# Do not immediately exit on error to allow the `assertSucceeded` function to handle the error.
#
# NOTE:
# Each statement should be followed by an `assertSucceeded`/`assertFailed` or `exit 1` statement.
set +e -x
2018-08-09 09:23:56 -04:00
PATH = $PATH :$( npm bin)
2019-09-05 16:45:58 -04:00
function assertFailed {
if [ [ $? -eq 0 ] ] ; then
echo " FAIL: $1 " ;
exit 1;
fi
}
function assertSucceeded {
if [ [ $? -ne 0 ] ] ; then
echo " FAIL: $1 " ;
exit 1;
fi
}
2019-10-14 05:51:02 -04:00
ngcc --help
assertSucceeded "Expected 'ngcc --help' to succeed."
2018-08-09 10:59:10 -04:00
2019-10-14 05:51:02 -04:00
# node --inspect-brk $(npm bin)/ngcc -f esm2015
2019-04-03 11:37:36 -04:00
# Run ngcc and check it logged compilation output as expected
2019-10-14 05:51:02 -04:00
ngcc | grep 'Compiling'
assertSucceeded "Expected 'ngcc' to log 'Compiling'."
2019-09-05 16:45:58 -04:00
2018-08-09 10:59:10 -04:00
2018-08-17 17:00:00 -04:00
# Did it add the appropriate build markers?
2019-03-20 09:47:58 -04:00
# - esm2015
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"esm2015": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'esm2015' in '@angular/common'."
2019-03-20 09:47:58 -04:00
2018-10-03 12:00:05 -04:00
# - fesm2015
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"fesm2015": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'fesm2015' in '@angular/common'."
2019-09-05 16:45:58 -04:00
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"es2015": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'es2015' in '@angular/common'."
2019-03-20 09:47:58 -04:00
# - esm5
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"esm5": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'esm5' in '@angular/common'."
2019-03-20 09:47:58 -04:00
# - fesm5
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"module": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'module' in '@angular/common'."
2019-09-05 16:45:58 -04:00
2019-06-03 14:39:30 -04:00
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"fesm5": "'
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add build marker for 'fesm5' in '@angular/common'."
2019-09-05 16:45:58 -04:00
2018-10-03 12:00:05 -04:00
refactor(ivy): obviate the Bazel component of the ivy_switch (#26550)
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
2018-10-17 18:44:44 -04:00
# Did it replace the PRE_R3 markers correctly?
grep "= SWITCH_COMPILE_COMPONENT__POST_R3__" node_modules/@angular/core/fesm2015/core.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to replace 'SWITCH_COMPILE_COMPONENT__PRE_R3__' in '@angular/core' (fesm2015)."
2019-09-05 16:45:58 -04:00
refactor(ivy): obviate the Bazel component of the ivy_switch (#26550)
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
2018-10-17 18:44:44 -04:00
grep "= SWITCH_COMPILE_COMPONENT__POST_R3__" node_modules/@angular/core/fesm5/core.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to replace 'SWITCH_COMPILE_COMPONENT__PRE_R3__' in '@angular/core' (fesm5)."
2019-09-05 16:45:58 -04:00
2018-10-03 12:00:05 -04:00
# Did it compile @angular/core/ApplicationModule correctly?
2019-10-14 10:20:26 -04:00
grep "ApplicationModule.ɵmod = ɵɵdefineNgModule" node_modules/@angular/core/fesm2015/core.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (fesm2015)."
2019-09-05 16:45:58 -04:00
2019-10-14 10:20:26 -04:00
grep "ApplicationModule.ɵmod = ɵɵdefineNgModule" node_modules/@angular/core/fesm5/core.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (fesm5)."
2019-09-05 16:45:58 -04:00
2019-10-14 10:20:26 -04:00
grep "ApplicationModule.ɵmod = ɵngcc0.ɵɵdefineNgModule" node_modules/@angular/core/esm2015/src/application_module.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (esm2015)."
2019-09-05 16:45:58 -04:00
2019-10-14 10:20:26 -04:00
grep "ApplicationModule.ɵmod = ɵngcc0.ɵɵdefineNgModule" node_modules/@angular/core/esm5/src/application_module.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (esm5)."
2019-09-05 16:45:58 -04:00
2019-11-06 12:03:56 -05:00
# Did it place the `setClassMetadata` call correctly?
cat node_modules/@angular/core/fesm2015/core.js | awk 'ORS=" "' | grep "ApplicationRef.ctorParameters.*setClassMetadata(ApplicationRef"
assertSucceeded "Expected 'ngcc' to place 'setClassMetadata' after static properties like 'ctorParameters' in '@angular/core' (fesm2015)."
2018-10-03 12:00:05 -04:00
2018-11-11 18:07:42 -05:00
# Did it transform @angular/core typing files correctly?
2019-03-06 03:05:06 -05:00
grep "import [*] as ɵngcc0 from './src/r3_symbols';" node_modules/@angular/core/core.d.ts
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to add an import for 'src/r3_symbols' in '@angular/core' typings."
2019-09-05 16:45:58 -04:00
2019-10-14 18:28:01 -04:00
grep "static ɵinj: ɵngcc0.ɵɵInjectorDef<ApplicationModule>;" node_modules/@angular/core/core.d.ts
assertSucceeded "Expected 'ngcc' to add a definition for 'ApplicationModule.ɵinj' in '@angular/core' typings."
2019-09-05 16:45:58 -04:00
2018-11-11 18:07:42 -05:00
2019-01-02 17:25:58 -05:00
# Did it generate a base factory call for synthesized constructors correctly?
2019-12-03 07:39:16 -05:00
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm2015/table/table.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to generate a base factory for 'MatTable' in '@angular/material' (esm2015)."
2019-09-05 16:45:58 -04:00
2019-12-03 07:39:16 -05:00
grep "var ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm5/table/table.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to generate a base factory for 'MatTable' in '@angular/material' (esm5)."
2019-09-05 16:45:58 -04:00
2019-01-02 17:25:58 -05:00
2019-10-25 13:45:08 -04:00
# Did it generate an abstract directive definition for undecorated classes with inputs and view queries?
2019-12-03 07:39:16 -05:00
grep "_MatMenuBase.ɵdir = ɵngcc0.ɵɵdefineDirective({ type: _MatMenuBase" node_modules/@angular/material/esm2015/menu/menu.js
2019-10-25 13:45:08 -04:00
assertSucceeded "Expected 'ngcc' to generate an abstract directive definition for 'MatMenuBase' in '@angular/material' (esm2015)."
2019-09-05 16:45:58 -04:00
2019-12-03 07:39:16 -05:00
grep "_MatMenuBase.ɵdir = ɵngcc0.ɵɵdefineDirective({ type: _MatMenuBase" node_modules/@angular/material/esm5/menu/menu.js
2019-10-25 13:45:08 -04:00
assertSucceeded "Expected 'ngcc' to generate an abstract directive definition for 'MatMenuBase' in '@angular/material' (esm5)."
2019-09-05 16:45:58 -04:00
2019-06-03 12:41:47 -04:00
2019-07-27 09:14:55 -04:00
# Did it handle namespace imported decorators in UMD using `__decorate` syntax?
2019-09-05 16:45:58 -04:00
grep "type: i0.Injectable" node_modules/@angular/common/bundles/common.umd.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly handle '__decorate' syntax in '@angular/common' (umd)."
2019-09-05 16:45:58 -04:00
# (and ensure the @angular/common package is indeed using `__decorate` syntax)
grep "JsonPipe = __decorate(" node_modules/@angular/common/bundles/common.umd.js.__ivy_ngcc_bak
assertSucceeded "Expected '@angular/common' (umd) to actually use '__decorate' syntax."
2019-07-27 09:14:55 -04:00
# Did it handle namespace imported decorators in UMD using static properties?
2019-12-03 07:39:16 -05:00
grep "type: i0.Injectable," node_modules/@angular/cdk/bundles/cdk-a11y.umd.js
2019-10-14 05:51:02 -04:00
assertSucceeded "Expected 'ngcc' to correctly handle decorators via static properties in '@angular/cdk/a11y' (umd)."
2019-09-05 16:45:58 -04:00
# (and ensure the @angular/cdk/a11y package is indeed using static properties)
grep "FocusMonitor.decorators =" node_modules/@angular/cdk/bundles/cdk-a11y.umd.js.__ivy_ngcc_bak
assertSucceeded "Expected '@angular/cdk/a11y' (umd) to actually have decorators via static properties."
2019-07-05 06:19:11 -04:00
2019-12-23 09:07:34 -05:00
# Did it transform imports in UMD correctly?
# (E.g. no trailing commas, so that it remains compatible with legacy browsers, such as IE11.)
grep "factory(exports, require('rxjs'), require('rxjs/operators'))" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to not add trailing commas to CommonJS block in UMD."
grep "define('@angular/core', \['exports', 'rxjs', 'rxjs/operators'], factory)" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to not add trailing commas to AMD block in UMD."
grep "factory((global.ng = global.ng || {}, global.ng.core = {}), global.rxjs, global.rxjs.operators)" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to not add trailing commas to globals block in UMD."
grep "(this, (function (exports, rxjs, operators) {" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to not add trailing commas to factory function parameters in UMD."
fix(ngcc): do not collect private declarations from external packages (#34811)
Previously, while trying to build an `NgccReflectionHost`'s
`privateDtsDeclarationMap`, `computePrivateDtsDeclarationMap()` would
try to collect exported declarations from all source files of the
program (i.e. without checking whether they were within the target
package, as happens for declarations in `.d.ts` files).
Most of the time, that would not be a problem, because external packages
would be represented as `.d.ts` files in the program. But when an
external package had no typings, the JS files would be used instead. As
a result, the `ReflectionHost` would try to (unnecessarilly) parse the
file in order to extract exported declarations, which in turn would be
harmless in most cases.
There are certain cases, though, where the `ReflectionHost` would throw
an error, because it cannot parse the external package's JS file. This
could happen, for example, in `UmdReflectionHost`, which expects the
file to contain exactly one statement. See #34544 for more details on a
real-world failure.
This commit fixes the issue by ensuring that
`computePrivateDtsDeclarationMap()` will only collect exported
declarations from files within the target package.
Jira issue: [FW-1794](https://angular-team.atlassian.net/browse/FW-1794)
Fixes #34544
PR Close #34811
2020-01-15 14:54:36 -05:00
# Can it compile `@angular/platform-server` in UMD + typings without errors?
# (The CLI prefers the `main` property (which maps to UMD) over `module` when compiling `@angular/platform-server`.
# See https://github.com/angular/angular-cli/blob/e36853338/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/server.ts#L34)
rm -rf node_modules/@angular/platform-server && \
yarn install --cache-folder $cache --check-files && \
test -d node_modules/@angular/platform-server
assertSucceeded "Expected to re-install '@angular/platform-server'."
ngcc --properties main --target @angular/platform-server
assertSucceeded "Expected 'ngcc' to successfully compile '@angular/platform-server' (main)."
2018-10-03 12:00:05 -04:00
# Can it be safely run again (as a noop)?
2019-04-03 11:37:36 -04:00
# And check that it logged skipping compilation as expected
2019-10-14 05:51:02 -04:00
ngcc -l debug | grep 'Skipping'
assertSucceeded "Expected 'ngcc -l debug' to successfully rerun (as a noop) and log 'Skipping'."
2019-04-03 11:37:36 -04:00
2019-08-29 11:47:54 -04:00
# Does it process the tasks in parallel?
2019-10-14 05:51:02 -04:00
ngcc -l debug | grep 'Running ngcc on ClusterExecutor'
assertSucceeded "Expected 'ngcc -l debug' to run in parallel mode (using 'ClusterExecutor')."
2019-08-29 11:47:54 -04:00
2019-04-03 11:37:36 -04:00
# Check that running it with logging level error outputs nothing
2019-10-14 05:51:02 -04:00
ngcc -l error | grep '.'
assertFailed "Expected 'ngcc -l error' to not output anything."
2018-08-09 10:59:10 -04:00
2019-03-20 09:47:58 -04:00
# Does running it with --formats fail?
2019-10-14 05:51:02 -04:00
ngcc --formats fesm2015
assertFailed "Expected 'ngcc --formats fesm2015' to fail (since '--formats' is deprecated)."
2019-03-20 09:47:58 -04:00
2018-10-03 12:00:05 -04:00
# Now try compiling the app using the ngcc compiled libraries
2018-08-09 09:23:56 -04:00
ngc -p tsconfig-app.json
2019-09-05 16:45:58 -04:00
assertSucceeded "Expected the app to successfully compile with the ngcc-processed libraries."
2018-08-09 09:23:56 -04:00
2018-10-15 06:02:38 -04:00
# Did it compile the main.ts correctly (including the ngIf and MatButton directives)?
grep "directives: \[.*\.NgIf.*\]" dist/src/main.js
2019-09-05 16:45:58 -04:00
assertSucceeded "Expected the compiled app's 'main.ts' to list 'NgIf' in 'directives'."
2018-10-15 06:02:38 -04:00
grep "directives: \[.*\.MatButton.*\]" dist/src/main.js
2019-09-05 16:45:58 -04:00
assertSucceeded "Expected the compiled app's 'main.ts' to list 'MatButton' in 'directives'."
2019-10-14 05:51:02 -04:00
# 'ivy-ngcc' should fail with an appropriate error message.
ivy-ngcc
assertFailed "Expected 'ivy-ngcc' to fail (since it was renamed to 'ngcc')."
ivy-ngcc 2>& 1 | grep "Error: The 'ivy-ngcc' command was renamed to just 'ngcc'. Please update your usage."
assertSucceeded "Expected 'ivy-ngcc' to show an appropriate error message."