iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/packages/language-service/ivy/BUILD.bazel

30 lines
1.1 KiB
Python
Raw Normal View History

build: Add entry point for Ivy language service (#36864) This commit adds a new entry point for the Ivy version of language service. The entry point is just a shell for now, implementation will be added in subsequent PRs. The Ivy version of language service could be loaded from the NPM package via `require(@angular/language-service/bundles/ivy.umd.js)` PR Close #36864
2020-04-29 18:08:22 -04:00
load("//tools:defaults.bzl", "ts_library")
feat(language-service): [ivy] wrap ngtsc to handle typecheck files (#36930) This commit adds a Compiler interface that wraps the actual ngtsc compiler. The language-service specific compiler manages multiple typecheck files using the Project interface, creating and adding ScriptInfos as necessary. This commit also adds `overrideInlineTemplate()` method to the mock service so that we could test the Compiler diagnostics feature. PR Close #36930
2020-04-30 18:48:20 -04:00
package(default_visibility = ["//packages/language-service:__subpackages__"])
build: Add entry point for Ivy language service (#36864) This commit adds a new entry point for the Ivy version of language service. The entry point is just a shell for now, implementation will be added in subsequent PRs. The Ivy version of language service could be loaded from the NPM package via `require(@angular/language-service/bundles/ivy.umd.js)` PR Close #36864
2020-04-29 18:08:22 -04:00
ts_library(
name = "ivy",
srcs = glob(["*.ts"]),
deps = [
feat(language-service): introduce hybrid visitor to locate AST node (#38540) This commit introduces two visitors, one for Template AST and the other for Expression AST to allow us to easily find the node that most closely corresponds to a given cursor position. This is crucial because many language service APIs take in a `position` parameter, and the information returned depends on how well we can find a good candidate node. In View Engine implementation of language service, the search for the node and the processing of information to return the result are strongly coupled. This makes the code hard to understand and hard to debug because the stack trace is often littered with layers of visitor calls. With this new feature, we could test the "searching" part separately and colocate all the logic (aka hacks) that's required to retrieve an accurate span for a given node. Right now, only the most "narrow" node is returned by the main exported function `findNodeAtPosition`. If needed, we could expose the entire AST path, or expose other methods to provide more context for a node. Note that due to limitations in the template AST interface, there are a few known cases where microsyntax spans are not recorded properly. This will be dealt with in a follow-up PR. PR Close #38540
2020-08-12 19:13:02 -04:00
"//packages/compiler",
feat(language-service): [ivy] Parse Angular compiler options (#36922) Parse Angular compiler options in Angular language service. In View Engine, only TypeScript compiler options are read, Angular compiler options are not. With Ivy, there could be different modes of compilation, most notably how strict the templates should be checked. This commit makes the behavior of language service consistent with the Ivy compiler. PR Close #36922
2020-04-29 18:52:17 -04:00
"//packages/compiler-cli",
refactor(language-service): [Ivy] remove temporary compiler (#38310) Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see https://github.com/angular/angular/pull/38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
2020-07-31 00:26:02 -04:00
"//packages/compiler-cli/src/ngtsc/core",
"//packages/compiler-cli/src/ngtsc/core:api",
feat(language-service): Add diagnostics to suggest turning on strict mode (#40423) This PR adds a way for the language server to retrieve compiler options diagnostics via `languageService.getCompilerOptionsDiagnostics()`. This will be used by the language server to show a prompt in the editor if users don't have `strict` or `fullTemplateTypeCheck` turned on. Ref https://github.com/angular/vscode-ng-language-service/issues/1053 PR Close #40423
2021-01-13 17:52:29 -05:00
"//packages/compiler-cli/src/ngtsc/diagnostics",
refactor(language-service): [Ivy] remove temporary compiler (#38310) Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see https://github.com/angular/angular/pull/38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
2020-07-31 00:26:02 -04:00
"//packages/compiler-cli/src/ngtsc/file_system",
feat(language-service): complete attributes on elements (#40032) This commit adds attribute completion to the Language Service. It completes from 3 sources: 1. inputs/outputs of directives currently present on the element 2. inputs/outputs/attributes of directives in scope for the element, that would become present if the input/output/attribute was added 3. DOM properties and attributes We distinguish between completion of a property binding (`[foo|]`) and a completion in an attribute context (`foo|`). For the latter, bindings to the attribute are offered, as well as a property binding which adds the square bracket notation. To determine hypothetical matches (directives which would become present if a binding is added), directives in scope are scanned and matched against a hypothetical version of the element which has the attribute. PR Close #40032
2020-12-03 21:08:00 -05:00
"//packages/compiler-cli/src/ngtsc/imports",
refactor(language-service): [Ivy] remove temporary compiler (#38310) Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see https://github.com/angular/angular/pull/38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
2020-07-31 00:26:02 -04:00
"//packages/compiler-cli/src/ngtsc/incremental",
refactor(language-service): Use compiler APIs in Ivy to get definitions for external resources (#39476) Rather than re-reading component metadata that was already interpreted by the Ivy compiler, the Language Service should instead use the compiler APIs to get information it needs about the metadata. PR Close #39476
2020-10-21 14:01:10 -04:00
"//packages/compiler-cli/src/ngtsc/metadata",
perf(compiler-cli): refactor the performance tracing infrastructure (#41125) ngtsc has an internal performance tracing package, which previously has not really seen much use. It used to track performance statistics on a very granular basis (microseconds per actual class analysis, for example). This had two problems: * it produced voluminous amounts of data, complicating the analysis of such results and providing dubious value. * it added nontrivial overhead to compilation when used (which also affected the very performance of the operations being measured). This commit replaces the old system with a streamlined performance tracing setup which is lightweight and designed to be always-on. The new system tracks 3 metrics: * time taken by various phases and operations within the compiler * events (counters) which measure the shape and size of the compilation * memory usage measured at various points of the compilation process If the compiler option `tracePerformance` is set, the compiler will serialize these metrics to a JSON file at that location after compilation is complete. PR Close #41125
2021-03-15 18:23:03 -04:00
"//packages/compiler-cli/src/ngtsc/perf",
fix(compiler-cli): ensure the compiler tracks `ts.Program`s correctly (#41291) `NgCompiler` previously had a notion of the "next" `ts.Program`, which served two purposes: * it allowed a client using the `ts.createProgram` API to query for the latest program produced by the previous `NgCompiler`, as a starting point for building the _next_ program that incorporated any new user changes. * it allowed the old `NgCompiler` to be queried for the `ts.Program` on which all prior state is based, which is needed to compute the delta from the new program to ultimately determine how much of the prior state can be reused. This system contained a flaw: it relied on the `NgCompiler` knowing when the `ts.Program` would be changed. This works fine for changes that originate in `NgCompiler` APIs, but a client of the `TemplateTypeChecker` may use that API in ways that create new `ts.Program`s without the `NgCompiler`'s knowledge. This caused the `NgCompiler`'s concept of the "next" program to get out of sync, causing incorrectness in future incremental analysis. This refactoring cleans up the compiler's `ts.Program` management in several ways: * `TypeCheckingProgramStrategy`, the API which controls `ts.Program` updating, is renamed to the `ProgramDriver` and extracted to a separate ngtsc package. * It loses its responsibility of determining component shim filenames. That functionality now lives exclusively in the template type-checking package. * The "next" `ts.Program` concept is renamed to the "current" program, as the "next" name was misleading in several ways. * `NgCompiler` now wraps the `ProgramDriver` used in the `TemplateTypeChecker` to know when a new `ts.Program` is created, regardless of which API drove the creation, which actually fixes the bug. PR Close #41291
2021-03-19 20:06:10 -04:00
"//packages/compiler-cli/src/ngtsc/program_driver",
refactor(compiler-cli): implement `DeclarationNode` node type (#38959) Previously the `ConcreteDeclaration` and `InlineDeclaration` had different properties for the underlying node type. And the `InlineDeclaration` did not store a value that represented its declaration. It turns out that a natural declaration node for an inline type is the expression. For example in UMD/CommonJS this would be the `exports.<name>` property access node. So this expression is now used for the `node` of `InlineDeclaration` types and the `expression` property is dropped. To support this the codebase has been refactored to use a new `DeclarationNode` type which is a union of `ts.Declaration|ts.Expression` instead of `ts.Declaration` throughout. PR Close #38959
2020-09-29 15:42:20 -04:00
"//packages/compiler-cli/src/ngtsc/reflection",
refactor(language-service): [Ivy] remove temporary compiler (#38310) Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see https://github.com/angular/angular/pull/38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
2020-07-31 00:26:02 -04:00
"//packages/compiler-cli/src/ngtsc/shims",
"//packages/compiler-cli/src/ngtsc/typecheck",
"//packages/compiler-cli/src/ngtsc/typecheck/api",
fix(language-service): include compilerOptions.rootDir in rootDirs (#40243) When resolving references, the Ivy compiler has a few strategies it could use. For relative path, one of strategies is [`RelativePathStrategy`]( https://github.com/angular/angular/blob/master/packages/compiler-cli/src/ ngtsc/imports/README.md#relativepathstrategy). This strategy relies on `compilerOptions.rootDir` and `compilerOptions.rootDirs` to perform the resolution, but language service only passes `rootDirs` to the compiler, and not `rootDir`. In reality, `rootDir` is very different from `rootDirs` even though they sound the same. According to the official [TS documentation][1], > `rootDir` specifies the root directory of input files. Only use to control > the output directory structure with --outDir. > `rootDirs` is a list of root folders whose combined content represent the > structure of the project at runtime. See [Module Resolution documentation]( > https://www.typescriptlang.org/docs/handbook/ > module-resolution.html#virtual-directories-with-rootdirs) > for more details. For now, we keep the behavior between compiler and language service consistent, but we will revisit the notion of `rootDir` and how it is used later. Fix angular/vscode-ng-language-service#1039 [1]: https://www.typescriptlang.org/docs/handbook/compiler-options.html PR Close #40243
2020-12-22 18:07:45 -05:00
"//packages/compiler-cli/src/ngtsc/util",
refactor(language-service): pull out interfaces on package toplevel (#40621) Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on #40607 PR Close #40621
2021-01-28 15:43:37 -05:00
"//packages/language-service:api",
refactor(compiler-cli): provide a host to readConfiguration (#39619) Currently `readConfiguration` relies on the file system to perform disk utilities needed to read determine a project configuration file and read it. This poses a challenge for the language service, which would like to use `readConfiguration` to watch and read configurations dependent on extended tsconfigs (#39134). Challenges are at least twofold: 1. To test this, the langauge service would need to provide to the compiler a mock file system. 2. The language service uses file system utilities primarily through TypeScript's `Project` abstraction. In general this should correspond to the underlying file system, but it may differ and it is better to go through one channel when possible. This patch alleviates the concern by directly providing to the compiler a "ParseConfigurationHost" with read-only "file system"-like utilties. For the language service, this host is derived from the project owned by the language service. For more discussion see https://docs.google.com/document/d/1TrbT-m7bqyYZICmZYHjnJ7NG9Vzt5Rd967h43Qx8jw0/edit?usp=sharing PR Close #39619
2020-11-09 19:20:02 -05:00
"@npm//@types/node",
build: Add entry point for Ivy language service (#36864) This commit adds a new entry point for the Ivy version of language service. The entry point is just a shell for now, implementation will be added in subsequent PRs. The Ivy version of language service could be loaded from the NPM package via `require(@angular/language-service/bundles/ivy.umd.js)` PR Close #36864
2020-04-29 18:08:22 -04:00
"@npm//typescript",
],
)