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:
2020-02-02 09:03:34 -05:00
# Each statement should be followed by an `assert*` or `exit 1` statement.
2019-09-05 16:45:58 -04:00
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
}
2020-02-02 09:03:34 -05:00
function assertEquals {
local value1 = $1 ;
local value2 = $2 ;
if [ [ " $value1 " != " $value2 " ] ] ; then
echo " FAIL: Expected ' $value1 ' to equal ' $value2 '. "
exit 1;
fi
}
function assertNotEquals {
local value1 = $1 ;
local value2 = $2 ;
if [ [ " $value1 " = = " $value2 " ] ] ; then
echo " FAIL: Expected ' $value1 ' not to equal ' $value2 '. "
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
fix(ngcc): show helpful error when providing an invalid option (#36010)
Currently, when running the ngcc binary directly and provide an invalid option ngcc will not error out and the user might have a hard time telling why ngcc is behaving not as expected.
With this change we now output an actionable error:
```
yarn ngcc --unknown-option
Options:
--version Show version number [boolean]
-s, --source A path (relative to the working directory)
of the `node_modules` folder to process.
[default: "./node_modules"]
-p, --properties An array of names of properties in
package.json to compile (e.g. `module` or
`es2015`)
Each of these properties should hold the
path to a bundle-format.
If provided, only the specified properties
are considered for processing.
If not provided, all the supported format
properties (e.g. fesm2015, fesm5, es2015,
esm2015, esm5, main, module) in the
package.json are considered. [array]
-t, --target A relative path (from the `source` path) to
a single entry-point to process (plus its
dependencies).
--first-only If specified then only the first matching
package.json property will be compiled.
[boolean]
--create-ivy-entry-points If specified then new `*_ivy_ngcc`
entry-points will be added to package.json
rather than modifying the ones in-place.
For this to work you need to have custom
resolution set up (e.g. in webpack) to look
for these new entry-points.
The Angular CLI does this already, so it is
safe to use this option if the project is
being built via the CLI. [boolean]
--legacy-message-ids Render `$localize` messages with legacy
format ids.
The default value is `true`. Only set this
to `false` if you do not want legacy
message ids to
be rendered. For example, if you are not
using legacy message ids in your
translation files
AND are not doing compile-time inlining of
translations, in which case the extra
message ids
would add unwanted size to the final source
bundle.
It is safe to leave this set to true if you
are doing compile-time inlining because the
extra
legacy message ids will all be stripped
during translation.
[boolean] [default: true]
--async Whether to compile asynchronously. This is
enabled by default as it allows
compilations to be parallelized.
Disabling asynchronous compilation may be
useful for debugging.
[boolean] [default: true]
-l, --loglevel The lowest severity logging message that
should be output.
[choices: "debug", "info", "warn", "error"]
--invalidate-entry-point-manifest If this is set then ngcc will not read an
entry-point manifest file from disk.
Instead it will walking the directory tree
as normal looking for entry-points, and
then write a new manifest file.
[boolean] [default: false]
--help Show help [boolean]
Unknown arguments: unknown-option, unknownOption
```
PR Close #36010
2020-03-11 07:42:56 -04:00
ngcc --unknown-option 2>& 1 | grep 'Unknown arguments: unknown-option, unknownOption'
assertSucceeded "Expected ngcc to report bad option."
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
2020-05-06 10:54:44 -04:00
# `es2015` is an alias of `fesm2015`.
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
2020-05-06 10:54:44 -04:00
# `module` is an alias of `fesm2015`
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
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
2020-05-06 10:54:44 -04:00
grep "= SWITCH_COMPILE_COMPONENT__POST_R3__" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to replace 'SWITCH_COMPILE_COMPONENT__PRE_R3__' in '@angular/core' (main)."
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
2020-05-06 10:54:44 -04:00
grep "ApplicationModule.ɵmod = ɵɵdefineNgModule" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (main)."
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-11-06 12:03:56 -05:00
# Did it place the `setClassMetadata` call correctly?
2020-05-27 17:09:01 -04:00
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)."
2019-11-06 12:03:56 -05:00
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?
2020-07-29 15:31:27 -04:00
grep "const ɵMatTable_BaseFactory = /\*@__PURE__\*/ ɵ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
2020-07-29 15:31:27 -04:00
grep "var ɵMatTable_BaseFactory = /\*@__PURE__\*/ ɵ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
2020-05-27 17:09:01 -04:00
# TODO: This assertion is disabled because @angular/common no longer contains __decorate calls.
# We should either remove this assertion or use a syntentic JS file as input.
# Discuss with the ngcc folks.
2019-07-27 09:14:55 -04:00
# Did it handle namespace imported decorators in UMD using `__decorate` syntax?
2020-05-27 17:09:01 -04:00
#grep "type: i0.Injectable" node_modules/@angular/common/bundles/common.umd.js
#assertSucceeded "Expected 'ngcc' to correctly handle '__decorate' syntax in '@angular/common' (umd)."
2019-09-05 16:45:58 -04:00
2020-05-27 17:09:01 -04:00
# TODO: This assertion is disabled because @angular/common no longer contains __decorate calls.
# We should either remove this assertion or use a syntentic JS file as input.
# Discuss with the ngcc folks.
2019-09-05 16:45:58 -04:00
# (and ensure the @angular/common package is indeed using `__decorate` syntax)
2020-05-27 17:09:01 -04:00
#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-09-05 16:45:58 -04:00
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."
2020-02-02 09:03:34 -05:00
# Can it correctly clean up and re-compile when dependencies are already compiled by a different version?
readonly actualNgccVersion = ` node --print "require('@angular/compiler-cli/package.json').version" `
readonly mockNgccVersion = "3.0.0"
# Mock the ngcc version marker on a package to make it appear as if it is compiled by a different ngcc version.
node mock-ngcc-version-marker @angular/material/button $mockNgccVersion
assertSucceeded "Expected to successfully mock the 'ngcc' version marker in '@angular/material/button'."
assertEquals $mockNgccVersion ` node --print "require('@angular/material/button/package.json').__processed_by_ivy_ngcc__.main" `
assertEquals 1 ` cat node_modules/@angular/material/button/button.d.ts | grep 'import \* as ɵngcc0' | wc -l`
# Re-compile packages (which requires cleaning up those compiled by a different ngcc version).
2020-04-17 09:19:31 -04:00
ngcc --properties main
2020-02-02 09:03:34 -05:00
assertSucceeded "Expected 'ngcc' to successfully re-compile the packages."
# Ensure previously compiled packages were correctly cleaned up (i.e. no multiple
# `import ... ɵngcc0` statements) and re-compiled by the current ngcc version.
assertEquals $actualNgccVersion ` node --print "require('@angular/material/button/package.json').__processed_by_ivy_ngcc__.main" `
assertEquals 1 ` cat node_modules/@angular/material/button/button.d.ts | grep 'import \* as ɵngcc0' | wc -l`
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)
2020-02-04 14:45:40 -05:00
if [ [ -z " $cache " ] ] ; then
cache = ".yarn_local_cache"
fi
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
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)."
2020-02-02 09:03:34 -05:00
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
2020-04-28 10:32:05 -04:00
# Does it timeout if there is another ngcc process running
LOCKFILE = node_modules/@angular/compiler-cli/ngcc/__ngcc_lock_file__
touch $LOCKFILE
trap " [[ -f $LOCKFILE ]] && rm $LOCKFILE " EXIT
ngcc
exitCode = $?
assertEquals $exitCode 177
rm $LOCKFILE
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."