angular/packages/compiler-cli/index.ts

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

56 lines
2 KiB
TypeScript
Raw Normal View History

/**
* @license
* Copyright Google LLC All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.dev/license
*/
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 19:22:32 +00:00
import {NodeJSFileSystem, setFileSystem} from './src/ngtsc/file_system';
export {VERSION} from './src/version';
export * from './src/ngtsc/transform/jit';
export * from './src/transformers/api';
export * from './src/transformers/entry_points';
export * from './src/perform_compile';
// TODO(tbosch): remove this once usages in G3 are changed to `CompilerOptions`
export {CompilerOptions as AngularCompilerOptions} from './src/transformers/api';
// Internal exports needed for packages relying on the compiler-cli.
// TODO: Remove this when the CLI has switched to the private entry-point.
export * from './private/tooling';
// Exposed as they are needed for relying on the `linker`.
export * from './src/ngtsc/logging';
export * from './src/ngtsc/file_system';
// Exports for dealing with the `ngtsc` program.
export {NgTscPlugin, PluginCompilerHost} from './src/ngtsc/tsc_plugin';
export {NgtscProgram} from './src/ngtsc/program';
export {OptimizeFor} from './src/ngtsc/typecheck/api';
build: switch all instances from `ng_rollup_bundle` to `app_bundle` (#44490) The `ng_rollup_bundle` rule has been replaced with a new rule called `app_bundle`. This rule replicates the Angular v13 optimization pipeline in the CLI, so that we can get better benchmarking results. Also the rule is much simpler to maintain as it relies on ESbuild. The old `ng_rollup_bundle` rule did rely on e.g. build-optimizer that no longer has an effect on v13 Angular packages, so technically size tests/symbol tests were no longer as correct as they were before. This commit fixes that. A couple of different changes and their explanation: * Language-service will no longer use the benchmark rule for creating its NPM bundles! It will use plain `rollup_bundle`. ESBuild would have been nice but the language-service relies on AMD that ESBuild cannot generate (yet?) * Service-worker ngsw-worker.js file was generated using the benchmark bundle rule. This is wrong. We will use a simple ESbuild rule in the future. The output is more predictable that way, and we can have a clear use of the benchmark bundle rule.. * A couple of benchmarks in `modules/` had to be updated to use e.g. `initTableUtils` calls. This is done because with the new rule, all files except for the entry-point are considered side-effect free. The utilities for benchmarks relied on side-effects in some transitively-loaded file (bad practice anyway IMO). We are now initializing the utilities using a proper init function that is exported... PR Close #44490
2021-12-15 15:22:01 +00:00
// **Note**: Explicit named exports to make this file work with CJS/ESM interop without
// needing to use a default import. NodeJS will expose named CJS exports as named ESM exports.
// TODO(devversion): Remove these duplicate exports once devmode&prodmode is combined/ESM.
export {ConsoleLogger, Logger, LogLevel} from './src/ngtsc/logging';
export {
NodeJSFileSystem,
absoluteFrom,
FileSystem,
AbsoluteFsPath,
NgtscCompilerHost,
getFileSystem,
setFileSystem,
isLocalRelativePath,
} from './src/ngtsc/file_system';
build: switch all instances from `ng_rollup_bundle` to `app_bundle` (#44490) The `ng_rollup_bundle` rule has been replaced with a new rule called `app_bundle`. This rule replicates the Angular v13 optimization pipeline in the CLI, so that we can get better benchmarking results. Also the rule is much simpler to maintain as it relies on ESbuild. The old `ng_rollup_bundle` rule did rely on e.g. build-optimizer that no longer has an effect on v13 Angular packages, so technically size tests/symbol tests were no longer as correct as they were before. This commit fixes that. A couple of different changes and their explanation: * Language-service will no longer use the benchmark rule for creating its NPM bundles! It will use plain `rollup_bundle`. ESBuild would have been nice but the language-service relies on AMD that ESBuild cannot generate (yet?) * Service-worker ngsw-worker.js file was generated using the benchmark bundle rule. This is wrong. We will use a simple ESbuild rule in the future. The output is more predictable that way, and we can have a clear use of the benchmark bundle rule.. * A couple of benchmarks in `modules/` had to be updated to use e.g. `initTableUtils` calls. This is done because with the new rule, all files except for the entry-point are considered side-effect free. The utilities for benchmarks relied on side-effects in some transitively-loaded file (bad practice anyway IMO). We are now initializing the utilities using a proper init function that is exported... PR Close #44490
2021-12-15 15:22:01 +00:00
// Export documentation entities for Angular-internal API doc generation.
export * from './src/ngtsc/docs';
// Exposed for usage in 1P Angular plugin.
export {isLocalCompilationDiagnostics, ErrorCode, ngErrorCode} from './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 19:22:32 +00:00
setFileSystem(new NodeJSFileSystem());