WIP: Fix nodePath issue #180
Conversation
|
This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request. |
1 similar comment
|
This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request. |
|
I added some trace statements around what I think is the problematic area to see if it can shed some light on the issue. I do not have an environment set up where I can test all of this locally against the |
| @@ -209,12 +209,23 @@ export function resolveModulePath(workspaceRoot: string, moduleName: string, nod | |||
| nodePath = path.join(workspaceRoot, nodePath); | |||
| } | |||
| return resolve(moduleName, nodePath, nodePath, tracer).then((value) => { | |||
| if (tracer) { | |||
| tracer(`Resolved module path is ${value}`); | |||
| } | |||
| if (value.indexOf(path.normalize(nodePath)) === 0) { | |||
There was a problem hiding this comment.
I think the issue lies with this indexOf check. It could be something as simple as c:/ vs C:/ in the path name.
Between this trace statement and the one in the else case, it should be hopefully be pretty clear what is going wrong.
|
I will close the PR since it only added logging. I implemented a correct path comparison depending on the OS the server is running. |
|
@dbaeumer Thank you so much! Will the fix be in the next version of VS Code? |
|
No, since VS Code doesn't ship the vscode-tslint extension. We first need to publish an official version of the libraries (version 3.2.0) and then vscode-tslint need to pull the new version in and deliver a new version. |
This PR aims to fix the issue described in #179 and vscode-tslint (#173).