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

83 lines
3.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
fix(ivy): ngcc - show logging via CLI by default (#29686) The new logger implementation caused a regression where by default the ngcc CLI did not output any logging messages. PR Close #29686
2019-04-03 11:37:36 -04:00
# Run ngcc and check it logged compilation output as expected
ivy-ngcc | grep 'Compiling'
if [[ $? != 0 ]]; then exit 1; fi
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
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?
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
# - esm2015
refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"esm2015":"' node_modules/@angular/common/package.json
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
if [[ $? != 0 ]]; then exit 1; fi
test(ivy): update ngcc integration test (#26236) PR Close #26236
2018-10-03 12:00:05 -04:00
# - fesm2015
refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"fesm2015":"' node_modules/@angular/common/package.json
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): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"es2015":"' node_modules/@angular/common/package.json
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
if [[ $? != 0 ]]; then exit 1; fi
# - esm5
refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"esm5":"' node_modules/@angular/common/package.json
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
if [[ $? != 0 ]]; then exit 1; fi
# - fesm5
refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"module":"' node_modules/@angular/common/package.json
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
if [[ $? != 0 ]]; then exit 1; fi
refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092) If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all the `propertiesToConsider` for that entry-point if we determine that it does not contain code that was compiled by Angular (for instance it has no `...metadata.json` file). The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since there may be entry-points that are marked despite ngcc not actually compiling anything. PR Close #29092
2019-03-20 09:47:59 -04:00
grep '"__processed_by_ivy_ngcc__":[^}]*"fesm5":"' node_modules/@angular/common/package.json
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
# 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?
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-17 21:49:21 -04: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
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-17 21:49:21 -04: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
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-17 21:49:21 -04: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
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-17 21:49:21 -04: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?
test: fix ngcc tests to work with flattened dts files (#28884) PR Close #28884
2019-03-06 03:05:06 -05:00
grep "import [*] as ɵngcc0 from './src/r3_symbols';" node_modules/@angular/core/core.d.ts
fix(ivy): let ngcc transform @angular/core typings with relative imports (#27055) PR Close #27055
2018-11-11 18:07:42 -05:00
if [[ $? != 0 ]]; then exit 1; fi
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-17 21:49:21 -04:00
grep "static ngInjectorDef: ɵngcc0.ɵɵInjectorDef<ApplicationModule>;" node_modules/@angular/core/core.d.ts
fix(ivy): let ngcc transform @angular/core typings with relative imports (#27055) PR Close #27055
2018-11-11 18:07:42 -05:00
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?
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-17 21:49:21 -04:00
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm2015/table.js
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
if [[ $? != 0 ]]; then exit 1; fi
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-17 21:49:21 -04:00
grep "const ɵMatTable_BaseFactory = ɵngcc0.ɵɵgetInheritedFactory(MatTable);" node_modules/@angular/material/esm5/table.es5.js
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
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)?
fix(ivy): ngcc - show logging via CLI by default (#29686) The new logger implementation caused a regression where by default the ngcc CLI did not output any logging messages. PR Close #29686
2019-04-03 11:37:36 -04:00
# And check that it logged skipping compilation as expected
fix(compiler-cli): log ngcc skipping messages as debug instead of info (#30232) Related to https://github.com/angular/angular-cli/issues/14194, https://github.com/angular/angular-cli/pull/14320 PR Close #30232
2019-05-02 04:34:01 -04:00
ivy-ngcc -l debug | grep 'Skipping'
fix(ivy): ngcc - show logging via CLI by default (#29686) The new logger implementation caused a regression where by default the ngcc CLI did not output any logging messages. PR Close #29686
2019-04-03 11:37:36 -04:00
if [[ $? != 0 ]]; then exit 1; fi
# Check that running it with logging level error outputs nothing
ivy-ngcc -l error | grep '.' && exit 1
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
feat(ivy): ngcc - compile only specified package.json format properties (#29092) You can now specify a list of properties in the package.json that should be considered (in order) to find the path to the format to compile. The build marker system has been updated to store the markers in the package.json rather than an additional external file. Also instead of tracking the underlying bundle format that was compiled, it now tracks the package.json property. BREAKING CHANGE: The `proertiesToConsider` option replaces the previous `formats` option, which specified the final bundle format, rather than the property in the package.json. If you were using this option to compile only specific bundle formats, you must now modify your usage to pass in the properties in the package.json that map to the format that you wish to compile. In the CLI, the `--formats` is no longer available. Instead use the `--properties` option. FW-1120 PR Close #29092
2019-03-20 09:47:58 -04:00
# Does running it with --formats fail?
ivy-ngcc --formats fesm2015 && exit 1
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