| 
									
										
										
										
											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 { | 
					
						
							|  |  |  | } |