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
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#45478
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#45478
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
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
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
As mentioned in the previous commit, integration tests will be declared
in subpackages of `//integration`. For these tests to still rely on the
NPM packages from `HEAD`, we need to update the visibility.
PR Close#44238
When we are going to the definition of an input, we find _both_ the
definition of the input _and_ also look for any directives which have
a selector that matches the input. For example:
```
@Directive({
selector: '[greeting]'
})
export class MyDir {
@Input() greeting!: string;
}
```
With this commit, we now correctly handle the case where inputs and/or
selectors have a dollar sign in them. The dollar sign has special
meaning in CSS, but when we encounter the dollar in a template, we need
to escape it when used as a selector so that it is taken as a dollar
literal rather than a character with special meaning.
Previously, we were not escaping the dollar sign and the CSS parsing
logic would throw an error. The change in this commit prevents that
error from happening, but a `try...catch` is still added in case there
is another unhandled use-case. If this happens, we do not want the
`goToDefinition` operation to completely fail.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1574
PR Close#44268
This commit removes most tests that were designated as only covering View
Engine code. It also removes tag filters from CI and local commands to run
tests.
In a few cases (such as with the packages/compiler tests), this tag was
improperly applied, and certain test cases have been added back running in
Ivy mode.
This commit also empties `@angular/compiler/testing` as it is no longer
necessary (this is safe since compiler packages are not public API). It can
be deleted in the future.
PR Close#43884
This commit moves code in the language service package out of the ivy
subfolder. Ivy is the _only_ engine supported in v13+ so there's no need
to have a name for it.
PR Close#44064
This commit removes ViewEngine-specific code from the langauge service
package. This code is no longer used since VE is not supported in v13+.
PR Close#44064
Using the tag "view-engine-only" better describes the expected usage of bazel targets with the test. They can
only be run with view engine.
PR Close#43862
This effectively enables extended template diagnostics in the VSCode extension in google3. This uses the existing `forceStrictTemplates` option to enable since that is already a prerequisite for extended template diagnostics and we don't distinguish between them at the configuration-level in google3 anyways.
PR Close#43708
This commit updates the `node` engines range for all Angular
framework packages to:
* No longer support NodeJS v12 `< 12.20`. This is done because APF v13
uses package export patterns which are only supported as of v12.20.
https://nodejs.org/api/packages.html#packages_subpath_patterns.
* Allows for the latest v16 NodeJS versions. This matches with the CLI
which added NodeJS v16 support with https://github.com/angular/angular-cli/pull/21854.
We already limit this to `>= v16.10.0` in preparation to only
supporting the LTS minors of Node v16.
BREAKING CHANGE: NodeJS versions older than `v12.20.0` are no longer
supported due to the Angular packages using the NodeJS package exports
feature with subpath patterns.
PR Close#43740
This commit removes the option to enable the VE language service and removes the VE bundle entirely.
It also updates the name of the ivy bundle to "language-service.js" now that there is only one.
PR Close#43723
Refs #42966.
Previously, checking a template with the syntax:
```html
<div>{{ foo() ?? 'test' }}</div>
```
Where `foo()` returns a nullable value:
```typescript
@Component(/* ... */)
class TestCmp {
foo: (): string | null => null;
}
```
Would always log a nullish coalescing not nullable warning. This is because [`getSymbolOfNode(node.left)`](https://github.com/angular/angular/blob/fe691935091aaf7090864c8111a15f7cc7e53b6c/packages/compiler-cli/src/ngtsc/typecheck/extended/checks/nullish_coalescing_not_nullable/index.ts#L30) would return the [symbol of the function (`foo`)](https://github.com/angular/angular/blob/fe691935091aaf7090864c8111a15f7cc7e53b6c/packages/compiler-cli/src/ngtsc/typecheck/src/template_symbol_builder.ts#L536-L538) rather than the symbol of its returned value (`foo()`). Fixed this by getting the symbol for the whole expression's span, rather than just the function receiver.
Also made some minor refactorings to `template_symbol_builder` to make a similar change to safe method calls. This behavior was originally for the language service in order to handle quick info, as the user highlighting a function name would actually apply to the entire expression. This is no longer true as the language service will correctly request the type from the function rather than the `Call` expression, so these hacks are not necessary anymore. This broke two existing test cases of exactly this behavior which were easily updated. Also added a test to the language service to confirm that it is not broken by this change.
PR Close#43572
Switches the compiler-cli usage of `__filename` to `import.meta.url`
when ESM bundles are generated. Unfortunately we cannot start using
only `import.meta` yet as we still build and run all code in Angular
in CommonJS module output for devmode tests.
This commit also fixes various instances where a jasmine spy was applied on
a namespace export that will break with ES module (and the interop for
CommonJS output). We fix these spies by using a default import.
PR Close#43431
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
The view engine language-service tests currently rely on the `npm_package` output
that is built locally. They rely on the package output mostly for
compiling test scenarios (with dependencies on e.g. forms), and for
the testing the metadata extraction (testing proper suggestions for VE).
The reliance on these packages becomes problematic with the new Angular
Package Format v13 where no metadata files are shipped. To continue
being able to test View Engine language-service compatibility, we will
use the v12.x framework packages for some of the test scenarios.
PR Close#43431
Native DOM events were previously not included in the completions
because the dom schema registry would filter out events completely. This
change updates the registry to include events in the private
element->property map and excludes events from lookups outside of the
new `allKnownEventsOfElement` function.
fixes https://github.com/angular/vscode-ng-language-service/issues/1479
PR Close#43299
Adds support for TypeScript 4.4. High-level overview of the changes made in this PR:
* Bumps the various packages to `typescript@4.4.2` and `tslib@2.3.0`.
* The `useUnknownInCatchVariables` compiler option has been disabled so that we don't have to cast error objects explicitly everywhere.
* TS now passes in a third argument to the `__spreadArray` call inside child class constructors. I had to update a couple of places in the runtime and ngcc to be able to pick up the calls correctly.
* TS now generates code like `(0, foo)(arg1, arg2)` for imported function calls. I had to update a few of our tests to account for it. See https://github.com/microsoft/TypeScript/pull/44624.
* Our `ngtsc` test setup calls the private `matchFiles` function from TS. I had to update our usage, because a new parameter was added.
* There was one place where we were setting the readonly `hasTrailingComma` property. I updated the usage to pass in the value when constructing the object instead.
* Some browser types were updated which meant that I had to resolve some trivial type errors.
* The downlevel decorators tranform was running into an issue where the Closure synthetic comments were being emitted twice. I've worked around it by recreating the class declaration node instead of cloning it.
PR Close#43281
Currently the compiler has three different classes to represent a "call to something":
1. `MethodCall` - `foo.bar()`
2. `SafeMethodCall` - `foo?.bar()`.
3. `FunctionCall` - Any calls that don't fit into the first two classes. E.g. `foo.bar()()`.
There are a few problems with this approach:
1. It is inconistent with the TypeScript AST which only has one node: `CallExpression`.
2. It means that we have to maintain more code, because the various parts of the compiler need to know about three node types.
3. It doesn't allow us to easily implement some new JS features like safe calls (e.g. `foo.bar?.())`).
These changes rework the compiler so that it produces only one node: `Call`. The new node behaves similarly to the TypeScript `CallExpression` whose `receiver` can be any expression.
There was a similar situation in the output AST where we had an `InvokeMethodExpression` and `InvokeFunctionExpression`. I've combined both of them into `InvokeFunctionExpression`.
PR Close#42882
When providing the completion for `SafePropertyRead`, the ts server
will not apply the optional chaining. So no need to shift the start
location of `replacementSpan` back.
PR Close#43321
Add a test to make sure extended template diagnostics are being correctly
generated in the language service for non-ts files.
Refs #42966
PR Close#43134
Return `TemplateDiagnostic` instead of `ts.Diagnostic` when getting the
extended template diagnostics. This makes the integration with the
language service easier. This also fixes the error code and now uses the
`ngErrorCode` for extended template diagnostics.
Refs #42966
PR Close#43134
This method is the @angular/language-service side of the implementation
for https://github.com/angular/vscode-ng-language-service/issues/1485
Given a location in a file, if the location is inside a component,
`getTemplateLocationForComponent` will return the `DocumentSpan` of the
inline `template` or the `DocumentSpan` for the file that the
`templateUrl` points to.
PR Close#43208
When the user tries to trigger suggestions from an interruption,
the LS should provide the global completions. For example,
`[input]="t¦"`, the `t` can be the `true` or the symbol from
the component context.
PR Close#42923
In combination with the TS `noImplicitOverride` compatibility changes,
we also want to follow the best-practice of adding `override` to
members which are implemented as part of abstract classes. This
commit fixes all instances which will be flagged as part of the
custom `no-implicit-override-abstract` TSLint rule.
PR Close#42512
Rollup just prints a warning if an import cannot be resolved and ends up
being treated as an external dependency. This in combination with the
`silent = True` attribute for `rollup_bundle` means that bundles might
end up being extremely small without people noticing that it misses
actual imports.
To improve this situation, the warning is replaced by an error if
an import cannot be resolved.
This unveiles an issue with the `ng_rollup_bundle` macro from
dev-infra where imports in View Engine were not resolved but ended
up being treated as external. This did not prevent benchmarks using
this macro from working because the ConcatJS devserver had builtin
resolution for workspace manifest paths. Though given the new check
for no unresolved imports, this will now cause errors within Rollup, and
we need to fix the resolution. We can fix the issue by temporarily
enabling workspace linking. This does not have any performance
downsides.
To enable workspace linking (which we might need more often in the
future given the linker taking over patched module resolution), we
had to rename the `angular` dependency to a more specific one so
that the Angular linker could link into `node_modules/angular`.
PR Close#42760
Source files that contain directives or components that need an inline
type constructor or inline template type-check block would always be
considered as affected in incremental rebuilds. The inline operations
cause the source file to be updated in the TypeScript program that is
created for template type-checking, which becomes the reuse program
in a subsequent incremental rebuild.
In an incremental rebuild, the source files from the new user program
are compared to those from the reuse program. The updated source files
are not the same as the original source file from the user program, so
the incremental engine would mark the file which needed inline
operations as affected. This prevents incremental reuse for these files,
causing sub-optimal rebuild performance.
This commit attaches the original source file for source files that have
been updated with inline operations, such that the incremental engine
is able to compare source files using the original source file.
Fixes#42543
PR Close#42759
Historically, our Language Service was built with the potential to be a
drop-in replacement for the TypeScript Language Service with the added
benefit of being able to provide Angular-specific information as well.
While our VSCode extension does not use the Language Service in this
way, it appears that other community-contributed plugins do. We don't
really officially support this use-case but there's not real reason for
us to override the TypeScript Language Service's
implementation in the VE Angular Language Service so that it returns
`undefined`. As with other non-implemented methods, we can just allow
this to be deferred to TSLS.
fixes#42715
PR Close#42727
Adds support for shorthand property declarations inside Angular templates. E.g. doing `{foo, bar}` instead of `{foo: foo, bar: bar}`.
Fixes#10277.
PR Close#42421
Andrew Scott