This fixes the definitions for signal-based inputs in the language
service and type checking symbol builder.
Signal inputs emit a slightly different output. The output works well
for comppletion and was designed to affect language service minimally.
Turns out there is a small adjustment needed for the definition symbols.
PR Close#54233
Given that the TCB output changes with signal inputs, and one of our
important considerations was auto-completion, we need some unit tests
that verify and guarantee proper completion with signal inputs being
bound in templates. This commit adds these.
PR Close#53808
Updates the repo to support TypeScript 5.3 and resolve any issues. Fixes include:
* Updating usages of TS compiler APIs to match their new signatures.
* In TS 5.3 negative numbers are represented as `PrefixUnaryExpression` instead of `NumericExpression`. These changes update all usages to account for it since passing a negative number into the old APIs results in a runtime error.
PR Close#52572
The `for` block has several parts which we know are required. This
commit improves the autocomplete snippet of the `for` block by adding
those required parts and providing placeholders.
PR Close#52405
Previously, autocompletions were not available in two main cases. We correct them.
1. Autocompletions immediately after `@` were usually not working, for example `foo @|`. We fix this by causing the lexer to not consider the `@` part of the text node.
2. Autocompletions such as `@\nfoo`, where a newline follows a bare `@`, were not working because the language service visitor considered us inside the subsequent text node. We fix this by adding a block name span for the block keyword, and special-case whether we are completing inside the name span. If we are, we don't continue to the following text node.
PR Close#52198
This commit introduces basic autocompletion support for the new block keywords. After typing `@`, the language service suggests the various block names.
PR Close#52121
Two key refactors to enable deeper language service support for blocks:
(1) We now generate accurate source spans for the various block types. Additionally, all the top-level source spans for a block are now *inclusive* of all the connected or descending blocks. This helps the language service visit connected blocks.
(2) The language service's template visitor was previously skipping over the AST nodes corresponding to several block types. We are now careful to visit all such nodes.
PR Close#52038
Adds an `UnknownBlock` node to the Ivy AST to represent blocks that haven't been recognized by the compiler. This will make it easier to integrate blocks into the language service.
PR Close#52047
When the `ts.Project` creates the language service plugin (in this case,
the Angular Language Service), it sets the project's language service to
the new language service returned by the plugin create:
https://sourcegraph.com/github.com/microsoft/TypeScript@b12af0fa2bbd4b015e59adcfb49988cea7f919a1/-/blob/src/server/project.ts?L2035-2044
The project may be reloaded in response to various events, such as a
change to the tsconfig file, which then recreates the plugin. When this
happens, the language service that gets passed to the plugin `create`
function will not be the typescript language service, but rather the
previous instance of the new language service returned by the last call
to `create`.
This commit ensures that subsequent calls to `create` for the
`NgLanguageService` plugin for a project after the first call are able
to retrieve and hold on to the _TypeScript_ language service.
fixes https://github.com/angular/vscode-ng-language-service/issues/1923
PR Close#51912
Adds support for template type checking inside `for` blocks. It is implemented by generating a JS `for...of` statement inside the TCB. The various loop variables (e.g. `$index`) are implemented by declaring a local number variable.
PR Close#51690
Adds support for template type checking inside `if` blocks. It is implemented by generating a JS `if` statement inside the TCB which allows us to do type narrowing of the expression. The `as` parameter is implemented by declaring a variable inside the `if` statement.
PR Close#51690
BREAKING CHANGE: Node.js v16 support has been removed and the minimum support version has been bumped to 18.13.0.
Node.js v16 is planned to be End-of-Life on 2023-09-11. Angular will stop supporting Node.js v16 in Angular v17. For Node.js release schedule details, please see: https://github.com/nodejs/release#release-schedule
PR Close#51755
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
Stores the `deferred` block triggers as a map instead of an array, because triggers can't be duplicated and because having to search through an array will be inconvenient later on.
I've also added a `DeferredBlock.visitAll` method to deduplicate the logic from the various visitor implementations.
PR Close#51262
Adds the logic to create `defer`-specific AST nodes from the generic HTML `BlockGroup` and `Block`. The logic for parsing the triggers will be in the next commit.
PR Close#51050
This commit updates the minimum supported Node version across packages from 16.13.0 -> 16.14.0 to ensure compatibility with dependencies.
PR Close#49771
BREAKING CHANGE: Node.js v14 support has been removed
Node.js v14 is planned to be End-of-Life on 2023-04-30. Angular will stop supporting Node.js v14 in Angular v16. Angular v16 will continue to officially support Node.js versions v16 and v18.
PR Close#49255
The options to generate NgFactory and NgSummary files were added to Ivy for backwards compatibility with ViewEngine. Since ViewEngine was deprecated and removed, the NgFactory and NgSummary files are no longer used as well.
This commit drops obsolete options to generate NgFactory and NgSummary files. Also, the logic that generates those files is also removed.
PR Close#48268
Reworks some of the existing compiler APIs to make them easier to use in a schematic and exposes a few new ones to surface information we already had. High-level list of changes:
* `getPotentialImportsFor` now requires a class reference, instead of a `PotentialDirective | PotentialPipe`.
* New `getNgModuleMetadata` method has been added to the type checker.
* New `getPipeMetadata` method has been added to the type checker.
* New `getUsedDirectives` method has been added to the type checker.
* New `getUsedPipes` method has been added to the type checker.
* The `decorator` property was exposed on the `TypeCheckableDirectiveMeta`. The property was already present at runtime, but it wasn't specified on the interface.
PR Close#48730
The TSLint rule for ESM/CJS interop was apparently not working
for a short period of time due to diverging TypeScript versions.
This commit fixes the lint warning to replace the type-only
import with a default import. Even thoughn not striclty needed
for types- the rule enforces a default import as that is the safer
approach for runtime imported symbols.
Also the rule is updated to not disallow `cluster` anymore. The
types for cluster do no allow for e.g. `cluster.Worker` if cluster
refers to the default import. The whole lint rule is not strictly
needed anymore since we build & test with ESM in this repo now!
PR Close#48731
A previous PR introduced a new compiler abstraction that tracks *all* known exports and re-exports of Angular traits. This PR harnesses that abstraction in the language service, in order to allow automatic imports of pipes.
PR Close#48354
Currently, the auto-import tests are very difficult to debug, because the `expect`ations are buried several function calls deep, and also because the multi-line replacements are hard to deal with. The auto-import tests now use a different approach, which can be easily debugged from the failure message. In addition, several new tests have been added to cover more cases.
PR Close#48354
The VSCode extension looks for `@angular/language-service/package.json`
using `require`. This currently breaks as of the ESM changes because
we introduced the `exports` field but did not expose the `package.json`.
This commit fixes it.
Co-authored-By: Andrew Scott <atscott@google.com>
Co-authored-By: Dylan Hunn <dylhunn@gmail.com>
PR Close#48678
The `/api` entry-point was accidentally dropped when we switched the
compilation in the repo to full ESM- thinking the entry-point is not
needed externally.
We re-add it because the VSCode repo extension relies on it for checking
whether `ts.LanguageService` is an Angular one.
PR Close#48670
The Angular Language Service package is now tested & compiled using ESM.
Previously it was a mismatch of CommonJS and ESM.
Still the language-service ESM output is transformed into a single UMD
bundle to allow for module resolution to be overriden. See
`bundles/BUILD`.
This is kept as is. To fully ship ESM (language-service is an exception
here), we need to:
* Update all code to no longer reference typescript via import. Instead
typescript needs to be passed around so that the extension can
control the version
* The VSCode extension/ the TS server needs to be able to load ESM. It
looks like the server supports ESM global plugins, but the extension
might not yet.
This is out of scope for the dev-infra effort as it requires more
insight into VSCode & the extension system & the TS language server.
PR Close#48521
Paul Gschwendtner