Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(language-service): do not treat file URIs as general URLs #39917

Closed
wants to merge 1 commit into from

Conversation

ayazhafiz
Copy link
Member

@ayazhafiz ayazhafiz commented Dec 1, 2020

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

@ayazhafiz ayazhafiz requested a review from kyliau Dec 1, 2020
@google-cla google-cla bot added the cla: yes label Dec 1, 2020
@ayazhafiz ayazhafiz added comp: language-service target: patch This PR is targeted for the next patch release type: bug/fix labels Dec 1, 2020
@ngbot ngbot bot modified the milestone: needsTriage Dec 1, 2020
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
kyliau
kyliau approved these changes Dec 3, 2020
@kyliau kyliau added the action: merge PR author is ready for this to merge label Dec 3, 2020
mhevery pushed a commit that referenced this issue Dec 3, 2020
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
@mhevery mhevery closed this in 3b70098 Dec 3, 2020
@angular-automatic-lock-bot
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Jan 3, 2021

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge PR author is ready for this to merge cla: yes comp: language-service target: patch This PR is targeted for the next patch release type: bug/fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants