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
`getPotentialPipes` returns possible pipes which can be used in the provided context, whether already in scope or requiring an import.
This is necessary to implement auto-import support for pipes in the language service.
PR Close#48090
The `fix_missing_import` quick fix has several generic helper functions that deal with imports and decorators, which I want to reuse for other import-related features. Move these functions into `ts_utils.ts` instead. No substantive code changes are present.
PR Close#48074
Currently, when generating an import of a selector, the language service might crash if the compiler cannot emit a reference to the new symbol's file from the target component's file. (This might happen because the two are the same file.) We should handle that case by reusing the existing import if possible, or otherwise failing gracefully.
PR Close#47938
This change allows the language service to suggest imports for *all* directives returned from the compiler, and for *all* import specifiers for each directive. The first change has immediate effect, since there could already be multiple directives with the same selector. The second change is future-proofing; the compiler currently only returns a single best specifier, but will return more in the future.
PR Close#47787
This change aligns with the supported Node.js versions of the Angular CLI.
See: https://github.com/angular/angular-cli/pull/24026
BREAKING CHANGE: Angular no longer supports Node.js versions `14.[15-19].x` and `16.[10-12].x`. Current supported versions of Node.js are `14.20.x`, `16.13.x` and `18.10.x`.
PR Close#47730
The language service can now generate an import corresponding to a selector. This includes both the TypeScript module import and the decorator import. This applies to both standalone components and components declared in NgModules.
PR Close#47088
After implementing `getPotentialTemplateDirectives`, we will use this data struture to represent both in-scope and out-of-scope directives. So this rename is an advance cleanup.
PR Close#47561
The Angular compiler will report the invalid banana in box, this code fixes
will try to fix the error and all the same errors in the selected file.
Fixes#44941
PR Close#47393
This option has no longer any effect as Ivy is the only rendering engine.
BREAKING CHANGE: Angular compiler option `enableIvy` has been removed as Ivy is the only rendering engine.
PR Close#47346
Create three new helper methods: `addElementToArrayLiteral`, `objectPropertyAssignmentForKey`, and `updateObjectValueForKey`. These methods make interacting with array and object literals easier.
These will be useful for the standalone imports feature, which will need to add new terms to import arrays in Component and NgModule decorators.
PR Close#47181
After a bugfix in #46096, the compiler is now better capable of detecting pipes
which require an inline type constructor. However, there is an issue in how all
pipes are considered when verifying the inline type-ctor requirement: it should
only check actually used pipes.
Fixes#46747
PR Close#46807
This commit adds an extended diagnostics check that is similar to the nullish
coalescing check, but targeting optional chains. If the receiver expression
of the optional chain is non-nullable, then the extended diagnostic can report
an error or warning that can be fixed by changing the optional chain into a
regular access.
Closes#44870
PR Close#46686
When an external template is read, adds the template file to to the project which contains.
This is necessary to keep the projects open when navigating away from HTML files.
Since a `tsconfig` cannot express including non-TS files,
we need another way to indicate the template files are considered part of the project.
Note that this does not ensure that the project in question _directly_ contains the component
file. That is, the project might just include the component file through the program rather
than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important
because the TypeScript language service/server prefers projects which _directly_ contain the TS
file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can
possibly be a different project used between the TS and HTML files.
For example, in Nx projects, the referenced configs are `tsconfig.app.json` and
`tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and
contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS
files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files
but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot
effectively express `projectContainsInfoDirectly` for HTML files.
We could consider also updating the language server implementation to attempt
to select the project to use for the template file based on which project
contains its component file directly, using either the internal `project.projectContainsInfoDirectly`
or as a workaround, check `project.isRoot(componentTsFile)`.
Finally, keeping the projects open is hugely important in the solution style config case like
Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not
`tsconfig.app.json`. However, if our extension does not also know to select
`tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined
first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in
keeping projects open when there is an HTML file open and (2) optionally attempt to do this
_only_ for projects that we know the TS language service will prioritize in TS files (i.e.,
attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close)
and prioritize that project for all requests.
fixes https://github.com/angular/vscode-ng-language-service/issues/1623
fixes https://github.com/angular/vscode-ng-language-service/issues/876
PR Close#45601
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
Previously, the compiler tracked directives and pipes in template scopes
separately. This commit refactors the scope system to unify them into a
single data structure, disambiguated by a `kind` field.
PR Close#45672
We allow the path to contain both the `t.BoundAttribute` and `t.BoundEvent` for two-way
bindings but do not want the path to contain both the `t.BoundAttribute` with its
children when the position is in the value span because we would then logically create a path
that also contains the `PropertyWrite` from the `t.BoundEvent`. This early return condition
ensures we target just `t.BoundAttribute` for this case and exclude `t.BoundEvent` children.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1626
PR Close#45582
Extends `TcbPosition` with a field that indicates whether the `tcbPath` is a
type-checking shim file, or an original source file with an inline type check
block.
This field is used in an upcoming commit that fixes an inconsistency with how
inline type check blocks are incorrectly interpreted as a type-checking shim
file instead.
PR Close#45454
Inline type check blocks (TCBs) are emitted into the original source file, but
node positions would still be represented as a `ShimLocation` with a `shimPath`
corresponding with the type-checking shim file. This results in inconsistencies,
as the `positionInShimFile` field of `ShimLocation` would not correspond with
the `shimPath` of that `ShimLocation`.
This commit is a precursor to letting `ShimLocation` also represent the correct
location for inline type check blocks, by renaming the interface to
`TcbLocation`. A followup commit addresses the actual inconsistency.
PR Close#45454
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
When authoring Angular templates, developers are likely to be most interested in
the current Directive/Component inputs and outputs, then potential
attributes which would match other directives to the element,
and lastly the plethora of DOM events and attributes.
This change ensures that Angular-specific information appears above DOM
information by prepending the first printable ASCII characters to the
sort text.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1537
PR Close#45293
Node.js v12 will become EOL on 2022-04-30. As a result, Angular CLI v14 will no longer support Node.js v12.
BREAKING CHANGE:
Support for Node.js v12 has been removed as it will become EOL on 2022-04-30. Please use Node.js v14.15 or later.
PR Close#45286
An `ng-template` with an inline template (i.e. has a structural
directive) would previously not get an `undefined` `tagName` because the
logic assumed the element would be `t.Element` or `t.Content` and read
the tag name from the `name` property. For a `t.Template`, this exists
instead on the `t.tagName`. The final result would be an `tagName` of `undefined`
for the parent `t.Template`, causing failures in the indexer downstream.
This `undefined` value is actually expected in the renderer code, even
though the type does not specify this possibility. This change updates
the type of `tagName` to be `string|null` and explicitly handles the
case where there is a structural directive on an `ng-template`. You can
see how the two are differentiated in the compliance code that was
modified in this commit.
PR Close#44788
When the user wants to rename a symbol in the ts file VSCode
will ask the rename providers for the answer in turn. If the
first extension returns the result, the VSCode will break the
loop and apply the result. If the first extension cannot rename
the symbol, VSCode will ask the second extension in the
list (built-in TS/JS extension, Angular LS extension, etc.).
In other words, VSCode takes the result from only one rename provider
and the order depends on registration timing, scoring.
Because the built-in ts extension and Angular extension have the
same high score, if the built-in ts extension is the
first(depends on the time the extension was registered), the result
will be provided by the built-in extension. We want Angular to
provide it, so this plugin will delegate rename requests and reject
the request for the built-in ts server.
The Angular LS only provides the rename info when working within
an Angular project. If we cannot locate Angular sources in the
project files, the built-in extension should provide the rename info.
This plugin will apply to the built-in TS/JS extension and delegate
rename requests to the Angular LS. It provides the rename info only
when it is an Angular project. Otherwise, it will return info by the
default built-in ts server rename provider.
See [here][1] for more info.
[1]: https://github.com/microsoft/vscode/issues/115354
PR Close#44696
Refs #42966.
There were two remaining places where `_extendedTemplateDiagnostics` needed to be set which should have been removed in #44712 but got missed. This updates them to only require `strictTemplates` and not `_extendedTemplateDiagnostics` so the feature is properly enabled in production.
PR Close#44777
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
Andrew Scott