2019-09-12 15:20:54 -07:00
|
|
|
/**
|
|
|
|
* @license
|
2020-05-19 12:08:49 -07:00
|
|
|
* Copyright Google LLC All Rights Reserved.
|
2019-09-12 15:20:54 -07:00
|
|
|
*
|
|
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
|
|
* found in the LICENSE file at https://angular.io/license
|
|
|
|
*/
|
|
|
|
|
|
|
|
import {CommonModule} from '@angular/common';
|
|
|
|
import {NgModule} from '@angular/core';
|
|
|
|
import {FormsModule} from '@angular/forms';
|
fix(language-service): do not treat file URIs as general URLs (#39917)
In the past, the legacy (VE-based) language service would use a
`UrlResolver` instance to resolve file paths, primarily for compiler
resources like external templates. The problem with this is that the
UrlResolver is designed to resolve URLs in general, and so for a path
like `/a/b/#c`, `#c` is treated as hash/fragment rather than as part
of the path, which can lead to unexpected path resolution (f.x.,
`resolve('a/b/#c/d.ts', './d.html')` would produce `'a/b/d.html'` rather
than the expected `'a/b/#c/d.html'`).
This commit resolves the issue by using Node's `path` module to resolve
file paths directly, which aligns more with how resources are resolved
in the Ivy compiler.
The testing story here is not great, and the API for validating a file
path could be a little bit prettier/robust. However, since the VE-based
language service is going into more of a "maintenance mode" now that
there is a clear path for the Ivy-based LS moving forward, I think it is
okay not to spend too much time here.
Closes https://github.com/angular/vscode-ng-language-service/issues/892
Closes https://github.com/angular/vscode-ng-language-service/issues/1001
PR Close #39917
2020-12-01 13:19:24 -06:00
|
|
|
import {InnerComponent} from './#inner/component';
|
2019-09-12 15:20:54 -07:00
|
|
|
import {AppComponent} from './app.component';
|
2019-10-14 15:24:59 -07:00
|
|
|
import * as ParsingCases from './parsing-cases';
|
2019-09-12 15:20:54 -07:00
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
imports: [CommonModule, FormsModule],
|
|
|
|
declarations: [
|
|
|
|
AppComponent,
|
fix(language-service): do not treat file URIs as general URLs (#39917)
In the past, the legacy (VE-based) language service would use a
`UrlResolver` instance to resolve file paths, primarily for compiler
resources like external templates. The problem with this is that the
UrlResolver is designed to resolve URLs in general, and so for a path
like `/a/b/#c`, `#c` is treated as hash/fragment rather than as part
of the path, which can lead to unexpected path resolution (f.x.,
`resolve('a/b/#c/d.ts', './d.html')` would produce `'a/b/d.html'` rather
than the expected `'a/b/#c/d.html'`).
This commit resolves the issue by using Node's `path` module to resolve
file paths directly, which aligns more with how resources are resolved
in the Ivy compiler.
The testing story here is not great, and the API for validating a file
path could be a little bit prettier/robust. However, since the VE-based
language service is going into more of a "maintenance mode" now that
there is a clear path for the Ivy-based LS moving forward, I think it is
okay not to spend too much time here.
Closes https://github.com/angular/vscode-ng-language-service/issues/892
Closes https://github.com/angular/vscode-ng-language-service/issues/1001
PR Close #39917
2020-12-01 13:19:24 -06:00
|
|
|
InnerComponent,
|
2020-01-12 14:15:50 -08:00
|
|
|
ParsingCases.CounterDirective,
|
2020-01-20 11:31:15 -08:00
|
|
|
ParsingCases.HintModel,
|
2019-10-14 15:24:59 -07:00
|
|
|
ParsingCases.NumberModel,
|
|
|
|
ParsingCases.StringModel,
|
|
|
|
ParsingCases.TemplateReference,
|
|
|
|
ParsingCases.TestComponent,
|
2020-03-27 15:32:51 +01:00
|
|
|
ParsingCases.TestPipe,
|
2020-02-19 20:38:21 +01:00
|
|
|
ParsingCases.WithContextDirective,
|
2020-10-02 13:54:18 -07:00
|
|
|
ParsingCases.CompoundCustomButtonDirective,
|
2020-10-12 12:48:56 -07:00
|
|
|
ParsingCases.EventSelectorDirective,
|
2019-09-12 15:20:54 -07:00
|
|
|
]
|
|
|
|
})
|
|
|
|
export class AppModule {
|
|
|
|
}
|