angular-cn/integration/ngcc/test.sh

238 lines
12 KiB
Bash
Raw Normal View History

#!/bin/bash
# Do not immediately exit on error to allow the `assertSucceeded` function to handle the error.
#
# NOTE:
# Each statement should be followed by an `assert*` or `exit 1` statement.
set +e -x
PATH=$PATH:$(npm bin)
function assertFailed {
if [[ $? -eq 0 ]]; then
echo "FAIL: $1";
exit 1;
fi
}
function assertSucceeded {
if [[ $? -ne 0 ]]; then
echo "FAIL: $1";
exit 1;
fi
}
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
}
ngcc --help
assertSucceeded "Expected 'ngcc --help' to succeed."
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."
# node --inspect-brk $(npm bin)/ngcc -f esm2015
# Run ngcc and check it logged compilation output as expected
ngcc | grep 'Compiling'
assertSucceeded "Expected 'ngcc' to log 'Compiling'."
# Did it add the appropriate build markers?
# - esm2015
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"esm2015": "'
assertSucceeded "Expected 'ngcc' to add build marker for 'esm2015' in '@angular/common'."
# - fesm2015
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"fesm2015": "'
assertSucceeded "Expected 'ngcc' to add build marker for 'fesm2015' in '@angular/common'."
# `es2015` is an alias of `fesm2015`.
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"es2015": "'
assertSucceeded "Expected 'ngcc' to add build marker for 'es2015' in '@angular/common'."
# `module` is an alias of `fesm2015`
cat node_modules/@angular/common/package.json | awk 'ORS=" "' | grep '"__processed_by_ivy_ngcc__":[^}]*"module": "'
assertSucceeded "Expected 'ngcc' to add build marker for 'module' in '@angular/common'."
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
assertSucceeded "Expected 'ngcc' to replace 'SWITCH_COMPILE_COMPONENT__PRE_R3__' in '@angular/core' (fesm2015)."
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)."
# Did it compile @angular/core/ApplicationModule correctly?
grep "ApplicationModule.ɵmod = ɵɵdefineNgModule" node_modules/@angular/core/fesm2015/core.js
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (fesm2015)."
grep "ApplicationModule.ɵmod = ɵɵdefineNgModule" node_modules/@angular/core/bundles/core.umd.js
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (main)."
grep "ApplicationModule.ɵmod = ɵngcc0.ɵɵdefineNgModule" node_modules/@angular/core/esm2015/src/application_module.js
assertSucceeded "Expected 'ngcc' to correctly compile 'ApplicationModule' in '@angular/core' (esm2015)."
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -04:00
# TODO: This assertion is disabled because @angular/core is no longer processed by tsickle which creates the static properties.
# We should either remove this assertion or use a syntentic JS file as input.
# Discuss with the ngcc folks.
#
# Did it place the `setClassMetadata` call correctly?
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -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)."
# Did it transform @angular/core typing files correctly?
grep "import [*] as ɵngcc0 from './src/r3_symbols';" node_modules/@angular/core/core.d.ts
assertSucceeded "Expected 'ngcc' to add an import for 'src/r3_symbols' in '@angular/core' typings."
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."
# Did it generate a base factory call for synthesized constructors correctly?
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm2015/table/table.js
assertSucceeded "Expected 'ngcc' to generate a base factory for 'MatTable' in '@angular/material' (esm2015)."
grep "var ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm5/table/table.js
assertSucceeded "Expected 'ngcc' to generate a base factory for 'MatTable' in '@angular/material' (esm5)."
# Did it generate an abstract directive definition for undecorated classes with inputs and view queries?
grep "_MatMenuBase.ɵdir = ɵngcc0.ɵɵdefineDirective({ type: _MatMenuBase" node_modules/@angular/material/esm2015/menu/menu.js
assertSucceeded "Expected 'ngcc' to generate an abstract directive definition for 'MatMenuBase' in '@angular/material' (esm2015)."
grep "_MatMenuBase.ɵdir = ɵngcc0.ɵɵdefineDirective({ type: _MatMenuBase" node_modules/@angular/material/esm5/menu/menu.js
assertSucceeded "Expected 'ngcc' to generate an abstract directive definition for 'MatMenuBase' in '@angular/material' (esm5)."
# Did it handle namespace imported decorators in UMD using `__decorate` syntax?
grep "type: i0.Injectable" node_modules/@angular/common/bundles/common.umd.js
assertSucceeded "Expected 'ngcc' to correctly handle '__decorate' syntax in '@angular/common' (umd)."
# (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."
# Did it handle namespace imported decorators in UMD using static properties?
grep "type: i0.Injectable," node_modules/@angular/cdk/bundles/cdk-a11y.umd.js
assertSucceeded "Expected 'ngcc' to correctly handle decorators via static properties in '@angular/cdk/a11y' (umd)."
# (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."
# 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."
# 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).
ngcc --properties main
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`
# 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)
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-04 14:45:40 -05:00
if [[ -z "$cache" ]]; then
cache=".yarn_local_cache"
fi
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)."
# Can it be safely run again (as a noop)?
# And check that it logged skipping compilation as expected
ngcc -l debug | grep 'Skipping'
assertSucceeded "Expected 'ngcc -l debug' to successfully rerun (as a noop) and log 'Skipping'."
# Does it process the tasks in parallel?
ngcc -l debug | grep 'Running ngcc on ClusterExecutor'
assertSucceeded "Expected 'ngcc -l debug' to run in parallel mode (using 'ClusterExecutor')."
# Check that running it with logging level error outputs nothing
ngcc -l error | grep '.'
assertFailed "Expected 'ngcc -l error' to not output anything."
# Does running it with --formats fail?
ngcc --formats fesm2015
assertFailed "Expected 'ngcc --formats fesm2015' to fail (since '--formats' is deprecated)."
# 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
# Now try compiling the app using the ngcc compiled libraries
ngc -p tsconfig-app.json
assertSucceeded "Expected the app to successfully compile with the ngcc-processed libraries."
# Did it compile the main.ts correctly (including the ngIf and MatButton directives)?
grep "directives: \[.*\.NgIf.*\]" dist/src/main.js
assertSucceeded "Expected the compiled app's 'main.ts' to list 'NgIf' in 'directives'."
grep "directives: \[.*\.MatButton.*\]" dist/src/main.js
assertSucceeded "Expected the compiled app's 'main.ts' to list 'MatButton' in 'directives'."
# '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."