iSharkFly-Docs/angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
angular-docs-cn/packages/compiler-cli/test/compliance/BUILD.bazel

34 lines
766 B
Python
Raw Normal View History

build(bazel): update to rules_typescript 0.17.0 & rules_nodejs 0.13.4 (#25920) PR Close #25920
2018-09-11 18:11:32 -07:00
load("//tools:defaults.bzl", "jasmine_node_test", "ts_library")
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
ts_library(
name = "test_lib",
test(ivy): mark failing test targets with fixme-ivy-jit and fixme-ivy-local tags (#26471) We are close enough to blacklist a few test targets, rather than whitelist targets to run... Because bazel rules can be composed of other rules that don't inherit tags automatically, I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and "ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even if those targets are composed of other targets that don't inherit this tag. This is the updated overview of ivy related bazel tags: - ivy-only: target that builds or runs only under ivy - fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit - fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local - no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit - no-ivy-local: target that is not intended to build or run under ivy with --compile=local PR Close #26471
2018-10-15 23:24:22 -07:00
testonly = True,
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
srcs = glob(
["**/*.ts"],
),
deps = [
"//packages:types",
"//packages/compiler",
"//packages/compiler-cli",
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 20:22:32 +01:00
"//packages/compiler-cli/src/ngtsc/file_system",
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
"//packages/compiler/test:test_utils",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 09:54:42 -08:00
"@npm//typescript",
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
],
)
jasmine_node_test(
name = "compliance",
test(ivy): run compiler compliance tests without rebuilding core,common (#25248) Previously the compiler compliance tests ran and built test code with real dependencies on @angular/core and @angular/common. This meant that any changes to the compiler would result in long rebuild processes for tests to rerun. This change removes those dependencies and causes test code to be built against the fake_core stub of @angular/core that the ngtsc tests use. This change also removes the dependency on @angular/common entirely, as locality means it's possible to reference *ngIf without needing to link to an implementation. PR Close #25248
2018-08-01 09:52:34 +02:00
bootstrap = ["angular/tools/testing/init_node_no_angular_spec.js"],
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
data = [
test(ivy): run compiler compliance tests without rebuilding core,common (#25248) Previously the compiler compliance tests ran and built test code with real dependencies on @angular/core and @angular/common. This meant that any changes to the compiler would result in long rebuild processes for tests to rerun. This change removes those dependencies and causes test code to be built against the fake_core stub of @angular/core that the ngtsc tests use. This change also removes the dependency on @angular/common entirely, as locality means it's possible to reference *ngIf without needing to link to an implementation. PR Close #25248
2018-08-01 09:52:34 +02:00
"//packages/compiler-cli/test/ngtsc/fake_core:npm_package",
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
],
build: enable shard_count for some jasmine tests that have many specs (#31009) This partitions the spects across multiple processes so they run in parallel. PR Close #31009
2019-03-08 16:35:36 -08:00
shard_count = 4,
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
tags = [
"ivy-only",
],
deps = [
":test_lib",
test(ivy): run compiler compliance tests without rebuilding core,common (#25248) Previously the compiler compliance tests ran and built test code with real dependencies on @angular/core and @angular/common. This meant that any changes to the compiler would result in long rebuild processes for tests to rerun. This change removes those dependencies and causes test code to be built against the fake_core stub of @angular/core that the ngtsc tests use. This change also removes the dependency on @angular/common entirely, as locality means it's possible to reference *ngIf without needing to link to an implementation. PR Close #25248
2018-08-01 09:52:34 +02:00
"//tools/testing:node_no_angular",
refactor(ivy): run the compiler compliance tests against ngtsc (#24862) This commit moves the compiler compliance tests into compiler-cli, and uses ngtsc to run them instead of the custom compilation pipeline used before. Testing against ngtsc allows for validation of the real compiler output. This commit also fixes a few small issues that prevented the tests from passing. PR Close #24862
2018-07-12 15:10:55 -07:00
],
)
Reference in New Issue Copy Permalink