honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/compiler-cli/test/ngtsc/BUILD.bazel

37 lines
1.1 KiB
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 21:11:32 -04:00
load("//tools:defaults.bzl", "jasmine_node_test", "ts_library")
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
ts_library(
name = "ngtsc_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-16 02:24:22 -04:00
testonly = True,
test(ivy): refactor ngtsc tests to use an NgtscTestEnvironment helper (#26203) This commit gets ready for the introduction of ngtsc template type-checking tests by refactoring test environment setup into a custom helper. This helper will simplify the authoring of future ngtsc tests. Ngtsc tests previously returned a numeric error code (a la ngtsc's CLI interface) if any TypeScript errors occurred. The helper has the ability to run ngtsc and return the actual array of ts.Diagnostics, which greatly increases the ability to write clean tests. PR Close #26203
2018-09-25 18:35:03 -04:00
srcs = glob(["**/*.ts"]),
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
deps = [
"//packages/compiler",
"//packages/compiler-cli",
fix(ivy): produce ts.Diagnostics for NgModule scope errors (#29191) Previously, when the NgModule scope resolver discovered semantic errors within a users NgModules, it would throw assertion errors. TODOs in the codebase indicated these should become ts.Diagnostics eventually. Besides producing better-looking errors, there is another reason to make this change asap: these assertions were shadowing actual errors, via an interesting mechanism: 1) a component would produce a ts.Diagnostic during its analyze() step 2) as a result, it wouldn't register component metadata with the scope resolver 3) the NgModule for the component references it in exports, which was detected as an invalid export (no metadata registering it as a component). 4) the resulting assertion error would crash the compiler, hiding the real cause of the problem (an invalid component). This commit should mitigate this problem by converting scoping errors to proper ts.Diagnostics. Additionally, we should consider registering some marker indicating a class is a directive/component/pipe without actually requiring full metadata to be produced for it, which would allow suppression of errors like "invalid export" for such invalid types. PR Close #29191
2019-03-08 14:32:49 -05:00
"//packages/compiler-cli/src/ngtsc/diagnostics",
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 15:22:32 -04:00
"//packages/compiler-cli/src/ngtsc/file_system",
"//packages/compiler-cli/src/ngtsc/file_system/testing",
feat(ivy): integrate indexing pipeline with NgtscProgram (#31151) Add an IndexingContext class to store indexing information and a transformer module to generate indexing analysis. Integrate the indexing module with the rest of NgtscProgram and add integration tests. Closes #30959 PR Close #31151
2019-06-19 20:23:59 -04:00
"//packages/compiler-cli/src/ngtsc/indexer",
test(ivy): introduce route testing mode for ngtsc tests (#27697) This commit introduces a new mode for the NgtscTestEnvironment which builds the NgtscProgram and then asks for the list of lazy routes, instead of running the TS emit phase. PR Close #27697
2018-11-16 11:54:43 -05:00
"//packages/compiler-cli/src/ngtsc/routing",
feat(ivy): add source mappings to compiled Angular templates (#28055) During analysis, the `ComponentDecoratorHandler` passes the component template to the `parseTemplate()` function. Previously, there was little or no information about the original source file, where the template is found, passed when calling this function. Now, we correctly compute the URL of the source of the template, both for external `templateUrl` and in-line `template` cases. Further in the in-line template case we compute the character range of the template in its containing source file; *but only in the case that the template is a simple string literal*. If the template is actually a dynamic value like an interpolated string or a function call, then we do not try to add the originating source file information. The translator that converts Ivy AST nodes to TypeScript now adds these template specific source mappings, which account for the file where the template was found, to the templates to support stepping through the template creation and update code when debugging an Angular application. Note that some versions of TypeScript have a bug which means they cannot support external template source-maps. We check for this via the `canSourceMapExternalTemplates()` helper function and avoid trying to add template mappings to external templates if not supported. PR Close #28055
2019-02-08 17:10:21 -05:00
"//packages/compiler-cli/src/ngtsc/util",
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
"//packages/compiler-cli/test:test_utils",
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 15:22:32 -04:00
"//packages/compiler-cli/test/helpers",
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 12:54:42 -05:00
"@npm//source-map",
"@npm//typescript",
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
],
)
jasmine_node_test(
name = "ngtsc",
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 15:22:32 -04:00
timeout = "long",
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
bootstrap = ["angular/tools/testing/init_node_no_angular_spec.js"],
data = [
"//packages/compiler-cli/test/ngtsc/fake_core:npm_package",
],
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 19:35:36 -05:00
shard_count = 4,
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
deps = [
":ngtsc_lib",
"//tools/testing:node_no_angular",
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 12:54:42 -05:00
"@npm//minimist",
feat(ivy): first steps towards ngtsc mode (#23455) This commit adds a new compiler pipeline that isn't dependent on global analysis, referred to as 'ngtsc'. This new compiler is accessed by running ngc with "enableIvy" set to "ngtsc". It reuses the same initialization logic but creates a new implementation of Program which does not perform the global-level analysis that AngularCompilerProgram does. It will be the foundation for the production Ivy compiler. PR Close #23455
2018-04-06 12:53:10 -04:00
],
)