Update environmentService.ts to enable ENV defined extenstions-dir

[apwelsh]

This update allows VS Code users to define the desired extensions directory by means of an environment variable "vscode_config_ext", instead of having to rely on the command-line arguments. By providing a path to the extensions directory in an environment variable, VS Code is able to have a system or user defined extensions directory that does not require a wrapper script to launch code for the settings to take effect. This solution is similar to the npm ENV variable solution "npm_config_cache".

This is 1/2 of the solution for providing a portable solution to remove VS Code from the Windows roaming profile.

[mention-bot]

@apwelsh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @joaomoreno and @jrieken to be potential reviewers.

[msftclas]

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.
Thanks,
Microsoft Pull Request Bot

[joaomoreno]

This is 1/2 of the solution for providing a portable solution to remove VS Code from the Windows roaming profile.

How is an environment variable better than a command line argument in preventing a wrapper script?

[apwelsh]

A command line argument means that any time a user uses file association to open the program, the command line arguments are not applied. In Windows, on a network with roaming profiles, the user and extensions directory for a small workspace can easily grow to 1 GB in size. This impacts login/logout times as Windows my replicate the entire profile. Moving the data to a local profile, as sone have proposed also causes issues, in that the local profile is not stored on the network, and results in workspaces that cannot be shared.
The command line arguments can help, by relocating these folders to a network share, outside the scope of the roaming profile. The issue is that they dont propegate to file type associations, requires changing all shortcuts on the system the add the arguments, and prevents you from using the path to run the program w/o creating a launcher script to pass the arguments in for you, or mandating that you supply the arguments manually.

For a windows networking admin, this becomes a management nightmare, trying to change every user's install to inplement these changes, and then cleaning ip the roaming profiles for every accudental run of the program without the arguments.

Environment variables in Windows can be systen and user defined. This means an admin can define the system variable to permenantly override the default location of the directories, with no need to jump through exhausting hoops. In addition to the system envirinment variables that define a system wide relocation, each user can define their own user environment variable to override the system variables, and have their directory settings follow them to each system they use.
And they can just run the code.exe file without any special hacks.

[joaomoreno]

Thanks, that makes a lot of sense. We definitely could use a lot of insight from a sys admin perspective.

[apwelsh]

Any chance these changes will be integrated?

[apwelsh]

This would be a really nice feature. I allowed VSCode to pull in the latest update, and that wiped out my code.cmd customizations. As such, my windows roaming profile was polluted with nearly 1 GB of VS Code cruft that need housekeeping again. And then, of course, I had to track down my command line arguments to re-instate them in the default CMD file that launches code.exe

[apwelsh]

So, I guess that's it? This is not going to happen?

I provided you with a solution, and even though you do not have to accept my solution, implementing a viable solution that addresses our needs is badly needed.

1GB of cache and configuration files in a roaming network profile is unreasonable. Something needs to get fixed. If the community cannot get what it requests for very valid reasons, the community will tire of the work-around solutions, and will look elsewhere.

I took the time to provide a solution that has zero (0) negative impact on the current user base, is optional, and follows the same implementation techniques as yarn, npm, and other open source tools that this very project also relies upon.

Please consider implementing my two pull requests. If nobody uses the changes, it will go unnoticed. This is a very low risk change with a huge reward for networked users.

[joaomoreno]

@apwelsh Thanks for your contribution and concerns. As much as we'd like to, there isn't enough time to go over every issue/PR that comes into our plate in a timely fashion. This is going to happen, otherwise it would be closed.

[apwelsh]

Okay. Thanks.

…

On Jul 20, 2017 at 12:06 AM, <João Moreno ***@***.***)> wrote: @apwelsh (https://github.com/apwelsh) Thanks for your contribution and concerns. As much as we'd like to, there isn't enough time to go over every issue/PR that comes into our plate in a timely fashion. This is going to happen, otherwise it would be closed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#26849 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AOaU64Mx_cjinDXDJqtH-tVjeV1PorJaks5sPvxvgaJpZM4NeqEg).

[joaomoreno]

Renamed the variable to VSCODE_EXTENSIONS.

Many thanks for your contributions and apologies for the delays in merging them! 🍻

[apwelsh]

Thanks! I look forward to deployment.

[MicahZoltu]

I just updated to the latest version of VSCode and this environment variable wasn't available. I'm not sure how versioning/branching works, but is it safe to assume it won't be available until the next version?

[joaomoreno]

This will come in the next stable release.