Skip to content

Allow dynamic files script info to be created when not opened by client#20910

Merged
uniqueiniquity merged 3 commits into
microsoft:masterfrom
uniqueiniquity:allowDynamicNotOpenByClient
Dec 29, 2017
Merged

Allow dynamic files script info to be created when not opened by client#20910
uniqueiniquity merged 3 commits into
microsoft:masterfrom
uniqueiniquity:allowDynamicNotOpenByClient

Conversation

@uniqueiniquity
Copy link
Copy Markdown
Contributor

Currently, if a dynamic file is opened in VS, either the language service will fail to start or the file will be incorrectly added to an inferred project rather than the intended external project.
This change allows the script info for the dynamic file to be created as part of a call to openExternalProjects, thereby resolving the issue.

Copy link
Copy Markdown
Member

@sheetalkamat sheetalkamat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just is changing assert... That doesnt seem correct, wouldnt you need to handle the cases like https://github.com/Microsoft/TypeScript/pull/20910/files#diff-efa731ca7c6279501f903db87403d2beL1791 as well to handle the dynamic files? Can you add the test case that fails to get idea about whats really not working right now?

@uniqueiniquity
Copy link
Copy Markdown
Contributor Author

I can add a test case. Could you point me to some test cases that test similar code paths? I wasn't able to find any.

Regarding changing behavior in response to the new assert, it seems that the code already reflects the possibility of this new assert. For example, line 1789, which would be hit given this change, already handles dynamic files. The line you pointed out, 1791, is unaffected by this change, since this assert is already true if openedByClient is true.

@uniqueiniquity
Copy link
Copy Markdown
Contributor Author

uniqueiniquity commented Dec 27, 2017

Disregard my request for finding tests; I'll add a test to tsserverProjectSystem.ts.

});

it("external project for dynamic file", () => {
const file1 = {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

give the file a dynamic filename

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea with file1 was not for it to be the dynamic file, but to be the real version of the file. This may not be entirely necessary, I guess. Regardless, we don't actually open this file, we just make the host aware of it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You dont need this at all.. better to remove.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

@sheetalkamat
Copy link
Copy Markdown
Member

Regarding changing behavior in response to the new assert, it seems that the code already reflects the possibility of this new assert. For example, line 1789, which would be hit given this change, already handles dynamic files. The line you pointed out, 1791, is unaffected by this change, since this assert is already true if openedByClient is true.

What i meant is that if in your test case if you change projectFileName to say /a/b/c/someproj,proj you will have a problem. openFilesWithNonRootedDiskPath handles when the file name is not a rooted file name. The identity of the file would be mismatched by project and its program.. Program assumes the identity for non rooted file path by using currentDirectory + nonRooted file name (dynamic file is still non rooted from program's perspective). Since the current directory for the project depends on whats being supplied (if not valid name it is location of tsserver which is what your test case does at moment and hence you don't really see the issue that assert was validating) in that case the identity of the file would be /a/b/c/^ScriptDocument1 file1.ts but when you open file it wont match and would be something like /^ScriptDocument1 file1.ts and it wont find the external project. So this needs more work than just fixing assert

@uniqueiniquity
Copy link
Copy Markdown
Contributor Author

Understood. I will try to match the test case closer to what VS is actually calling and see what I might need to update.

@uniqueiniquity
Copy link
Copy Markdown
Contributor Author

After discussing separately with @sheetalkamat, I added another assertion explaining that dynamic script infos will always share the same name and project file name, and therefore will always have the tsserver location as the current directory.

@uniqueiniquity uniqueiniquity merged commit 196f1c2 into microsoft:master Dec 29, 2017
sheetalkamat added a commit that referenced this pull request Jan 23, 2018
[release-2.6] Pulling PRs #20910, #21107 and #21282 to release-2.6 branch
@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants