Crash on startup #1001
Comments
|
I suspect one of the external templates in your project does not exist on disk (could be a typo in |
|
Thank you for the support @kyliau 😊 In the meantime could you suggest any temporary fix? By the way, the same project opened on my macbook pro works fine... 🤔 The issue occurs with this project opened on my iMac, running HighSierra, while the macbook runs Mojave... |
|
@caiusCitriga what is the path of the project on your iMac? @kyliau I think the problem is a little more subtle and related to #892. For example, resolving a template path in the project path @caiusCitiriga gave will yield an incorrect path (f.x. I guess as a temporary fix, you could rename your project path(s) not contain |
|
@ayazhafiz hmmmm actually you've pointed out an important thing... now that you're speaking about the And indeed you were right! Removing the I'm pretty surprised though that Mac allows you to create a folder with a name that Ubuntu doesn't... 🤷♂️ |
|
Anyhow, to me wasn't a big issue changing the folder name, but I guess that it's not everyone's case. Still, I'm glad to have been helpful in finding out this issue 😊 |
…exist There is a bug in tsserver that causes it to crash when it tries to create script info for an external template that does not exist. I've submitted an upstream PR microsoft/TypeScript#41737 to fix this, but before the commit lands in the stable release, we'll have to workaround the issue in language service. Close angular/vscode-ng-language-service#1001
just an aside: ubuntu should let you, but maybe your shell doesn't. If you quote the filename or escape the |
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 angular/vscode-ng-language-service#892
Closes angular/vscode-ng-language-service#1001
…exist (#39898) There is a bug in tsserver that causes it to crash when it tries to create script info for an external template that does not exist. I've submitted an upstream PR microsoft/TypeScript#41737 to fix this, but before the commit lands in the stable release, we'll have to workaround the issue in language service. Close angular/vscode-ng-language-service#1001 PR Close #39898
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 angular/vscode-ng-language-service#892
Closes angular/vscode-ng-language-service#1001
PR Close #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 angular/vscode-ng-language-service#892
Closes angular/vscode-ng-language-service#1001
PR Close #39917
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Describe the bug
Angular language service crashes on startup opening an Angular 10 project.
Expected behavior
I've noticed this when my html template wasn't showing errors even when it should.
I can see that it doesn't find somethig, but I don't quite get what or how to solve it...
I've seen this issue before on this repo, but all the responses were pointing to some PRs that should have fixed this already...
If it can helps, the language service works on another Angular 8.1 application...
Logs
Please attach two logs:
The text was updated successfully, but these errors were encountered: