Support ~/ paths for typescript.tsdk

[smlombardi]

Issue Type: Bug

I am getting an error in the workspace:

The path /Users/st016lo/github/angular-material-test/~/.nvm/versions/node/v10.1.0/lib/node_modules doesn't point to a valid tsserver install. Falling back to bundled TypeScript version.

The first part of the error path is the project in question: /Users/st016lo/github/angular-material-test/ Not sure why this is being appended to what I put in my user settings.

My global version of Typescript is installed at
/Users/st016lo/.nvm/versions/node/v10.1.0/lib/node_modules

Wherein /Users/st016lo 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 added this to my settings.json:

  "typescript.tsdk": "~/.nvm/versions/node/v10.1.0/lib/node_modules",

What am I missing here?

VS Code version: Code - Insiders 1.30.0-insider (9e62a05, 2018-12-03T06:12:08.874Z)
OS version: Darwin x64 18.2.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2800)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled rasterization: enabled video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	3, 3, 3
Memory (System)	16.00GB (0.56GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (34)

Extension	Author (truncated)	Version
better-comments	aar	2.0.3
vscode-svgo	ajh	0.1.0
Bookmarks	ale	10.0.0
project-manager	ale	10.0.0
ACF-Snippet	ant	1.9.0
bracket-pair-colorizer	Coe	1.0.61
vscode-eslint	dba	1.7.0
tslint	eg2	1.0.40
vscode-npm-script	eg2	0.3.5
vscode-great-icons	emm	2.1.45
prettier-vscode	esb	1.7.2
auto-rename-tag	for	0.0.15
path-autocomplete	ion	1.13.1
svg	joc	0.1.4
ecdc	mit	0.12.0
HTMLHint	mka	0.5.0
theme-monokai-pro-vscode	mon	1.1.9
vscode-scss	mrm	0.6.2
vscode-stylefmt	mrm	2.5.0
debugger-for-chrome	msj	4.11.1
angular2-inline	nat	0.0.17
incrementor	nms	0.1.0
vscode-html-scss	P-d	0.0.42
vscode-versionlens	pfl	0.22.0
polacode	pnp	0.2.2
quicktype	qui	12.0.46
LiveServer	rit	5.3.1
code-settings-sync	Sha	3.2.2
stylelint	shi	0.47.0
rewrap	stk	1.9.1
ayu	tea	0.17.0
sort-lines	Tyr	1.7.0
vscode-terminal-here	Tyr	0.1.1
change-case	wma	1.0.0

(3 theme extensions excluded)

[mjbvz]

We only support workspace relative or absolute paths for tsdk (not shell conventions like ~). A few extensions such as python use libraries like this one to support ~ paths.

I've updated the title and have marked as a feature request. The setting we'd want to support is:

    "typescript.tsdk": "~/.nvm/versions/node/v10.1.0/lib/node_modules/typescript/lib",

[smlombardi]

Or, like the project manager extension does it, with a $home

[skprabhanjan]

@mjbvz , Can i take a look at this?
Some starter points would be helpful ,thanks :)

[ecraig12345]

Rather than just supporting ~ in paths for typescript.tsdk, 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.

[skprabhanjan]

@ecraig12345 , CC : @mjbvz
I agree to the point, So what would be the next step with this issue ?
Thanks :)

[ecraig12345]

Did a search and the code to read the raw typescript.tsdk setting is here and the code to resolve the path is here. Part of the path resolution is done with the RelativePathResolver utility, but that's only used within the typescript-language-features extension. So unfortunately that means supporting ~ in all setting paths would not be straightforward.

[mjbvz]

Thanks @ecraig12345. Yep that all sounds correct

This issue has been discussed in #2809. @sandy081 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

[sandy081]

#2809 is all about supporting variables in settings. Not sure what you mean by TS specific workaround. But one solution I am thinking for #2809 is have an additional API in configuration that returns a resolved value.