Change:
*--------------------------------------------------------------------------------------------*/ import * as vscode from 'vscode'; import * as arrays from './arrays'; <ins> import * as os from 'os'; </ins> export enum TsServerLogLevel { Off,

Discussion:
Issue Type: <bBug</bI am getting an error in the workspace: The first part of the error path is the project in question: Not sure why this is being appended to what I put in my user settings. My global version of Typescript is installed at Wherein is my home directory. I don't want to use the absolute path as I synchronize settings with another mac with a different home folder name and want this to work on both. I have this to my What am I missing here? VS Code version: Code - Insiders 1.30.0-insider (, 2018-12-03T06:12:08.874Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (34)</summaryExtensionVersion ------ better-comments2.0.3 vscode-svgo0.1.0 Bookmarks10.0.0 project-manager10.0.0 ACF-Snippet1.9.0 bracket-pair-colorizer1.0.61 vscode-eslint1.7.0 tslint1.0.40 vscode-npm-script0.3.5 vscode-great-icons2.1.45 prettier-vscode1.7.2 auto-rename-tag0.0.15 path-autocomplete1.13.1 svg0.1.4 .12.0 HTMLHint0.5.0 theme-monokai-pro-vscode1.1.9 vscode-scss0.6.2 vscode-stylefmt2.5.0 debugger-for-chrome4.11.1 angular2-inline0.0.17 incrementor0.1.0 vscode-html-scss0.0.42 vscode-versionlens0.22.0 polacode0.2.2 quicktype12.0.46 LiveServer5.3.1 code-settings-sync3.2.2 stylelint0.47.0 rewrap1.9.1 ayu0.17.0 sort-lines1.7.0 vscode-terminal-here0.1.1 change-case1.0.0 (3 theme extensions excluded) </details<!-- generated by issue reporter --
We only support workspace relative or absolute paths for tsdk (not shell conventions like ). A few extensions such as python use libraries like to support paths. I've updated the title and have marked as a feature request.

The setting we'd want to support is:
Or, like the project manager extension does it, with a
, Can i take a look at this? Some starter points would be helpful ,thanks :)
Rather than just supporting ~ in paths for , shouldn't it be supported in all setting paths? I'd hope that the code for resolving paths would be shared and used for all settings (not duplicated)--if so, fixing this once for all settings should be straightforward.
, CC : I agree to the point, So what would be the next step with this issue ? Thanks :)
Did a search and the code to read the raw setting is and the code to resolve the path is . Part of the path resolution is done with the , but that's only used within the extension. So unfortunately that means supporting in all setting paths would not be straightforward.
Thanks Yep that all sounds correct This issue has been discussed in . what are your thoughts about a TS specific workaround? Python and a few other extensions already seem to support paths with , but I don't know if any built-in extensions handle this yet
is all about supporting variables in settings. Not sure what you mean by TS specific workaround. But one solution I am thinking for is have an additional API in configuration that returns a resolved value.
The workaround we'd add for typescript would be supporting settings paths like: or . These would only be supported for the tsdk setting Do you have any objections to supporting a convention like this for a single extension setting, or would you prefer we wait for to provide a consistent solution?
Not sure how can this be done only for setting unless we hardcode it in the platform. If so, I would prefer to do it for all and not have inconsistency too.
The proposal is to have code in the TypeScript extension that reads that string value of and then replaces with the user's home directory. I think supporting is safer (but less cross-platform) than inventing our own, typescript extension specific variable substitution language, with something like Do you still want to take a look at handling this? As mentioned, here's code in the TS extension that would need to be changed (both and ): You can use node's  to get the home directory.
, I will surely work on this, Was just waiting on your confirmation for going ahead :) Thanks :)
Ah you want to resolve this in typescript extension.

I do not have any issues having your own format, but if is supported, then we will have support for same variables we already support in debug and tasks land.