honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/integration/ngcc/test.sh

59 lines
2.5 KiB
Bash
Raw Normal View History

test(ivy): add an integration test for ngcc (#25406) 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
2018-08-09 09:23:56 -04:00
#!/bin/bash
feat(ivy): find all packages to be compiled by ngcc (#25406) PR Close #25406
2018-08-09 08:54:20 -04:00
set -e -x
test(ivy): add an integration test for ngcc (#25406) 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
2018-08-09 09:23:56 -04:00
PATH=$PATH:$(npm bin)
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
ivy-ngcc --help
# node --inspect-brk $(npm bin)/ivy-ngcc -f esm2015
ivy-ngcc
feat(ivy): implement ngcc build marker (#25557) `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
2018-08-17 17:00:00 -04:00
# Did it add the appropriate build markers?
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
# - fesm2015
ls node_modules/@angular/common | grep __modified_by_ngcc_for_fesm2015
if [[ $? != 0 ]]; then exit 1; fi
# - esm2015
ls node_modules/@angular/common | grep __modified_by_ngcc_for_esm2015
if [[ $? != 0 ]]; then exit 1; fi
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
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
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
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
# Did it compile @angular/core/ApplicationModule correctly?
fix(ivy): prevent ngcc from referencing missing ɵsetClassMetadata (#27055) 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
2018-11-11 13:16:04 -05:00
grep "ApplicationModule.ngModuleDef = defineNgModule" node_modules/@angular/core/fesm2015/core.js
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
fix(ivy): prevent ngcc from referencing missing ɵsetClassMetadata (#27055) 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
2018-11-11 13:16:04 -05:00
grep "ApplicationModule.ngModuleDef = defineNgModule" node_modules/@angular/core/fesm5/core.js
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
fix(ivy): prevent ngcc from referencing missing ɵsetClassMetadata (#27055) 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
2018-11-11 13:16:04 -05:00
grep "ApplicationModule.ngModuleDef = ɵngcc0.defineNgModule" node_modules/@angular/core/esm2015/src/application_module.js
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
fix(ivy): prevent ngcc from referencing missing ɵsetClassMetadata (#27055) 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
2018-11-11 13:16:04 -05:00
grep "ApplicationModule.ngModuleDef = ɵngcc0.defineNgModule" node_modules/@angular/core/esm5/src/application_module.js
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi
fix(ivy): let ngcc transform @angular/core typings with relative imports (#27055) PR Close #27055
2018-11-11 18:07:42 -05:00
# Did it transform @angular/core typing files correctly?
grep "import [*] as ɵngcc0 from './r3_symbols';" node_modules/@angular/core/src/application_module.d.ts
if [[ $? != 0 ]]; then exit 1; fi
grep "static ngInjectorDef: ɵngcc0.InjectorDef<ApplicationModule>;" node_modules/@angular/core/src/application_module.d.ts
if [[ $? != 0 ]]; then exit 1; fi
fix(ivy): ngcc - recognize synthesized constructors (#27897) 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
2019-01-02 17:25:58 -05:00
# Did it generate a base factory call for synthesized constructors correctly?
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm2015/table.js
if [[ $? != 0 ]]; then exit 1; fi
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm5/table.es5.js
if [[ $? != 0 ]]; then exit 1; fi
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
# Can it be safely run again (as a noop)?
ivy-ngcc
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
# Now try compiling the app using the ngcc compiled libraries
test(ivy): add an integration test for ngcc (#25406) 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
2018-08-09 09:23:56 -04:00
ngc -p tsconfig-app.json
test(ivy): ngcc - test compiling the Angular Material library (#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
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
if [[ $? != 0 ]]; then exit 1; fi
grep "directives: \[.*\.MatButton.*\]" dist/src/main.js
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
if [[ $? != 0 ]]; then exit 1; fi