NodeJS Environment Variables within launch.json are undefined if they contain the _ (underscore) character

[BenLBartle]

Issue Type

Bug

Description

Reproduceton Steps:

Create a NodeJS application, and add the required configuration to the the launch.json file:

"type": "node",
           "request": "launch",
           "name": "<Name>",
           "program": "${workspaceFolder}/<folder>/app.js",
           "env": {
               "INVALID_VALUE": "C:\\Temp\\file.zip",
               "VALIDVALUE": "C:\\Temp\\file.zip"
           }

When debugging, "proces.env["INVALID_VALUE"] is always undefined. However process.env["VALIDVALUE"] always returns a value (even if the two variables have the same defined value as per the example above. Not a problem if you are in control of the environment variable names, but in the vsts-task-lib always expects input values to be prefixed "INPUT_".

When running the application outside the debugger, and setting the environment variables via the console, they are defined as expected.

VS Code Info

VS Code version: Code 1.20.1 (f88bbf9, 2018-02-13T15:34:36.336Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 x 2295)
Memory (System)	7.88GB (1.34GB free)
Process Argv	C:\Program Files\Microsoft VS Code\Code.exe
Screen Reader	no
VM	0%

Extensions (7)

Extension	Author (truncated)	Version
vscode-eslint	dba	1.4.7
tslint	eg2	1.0.28
Angular-BeastCode	Mik	5.2.16
csharp	ms-	1.14.0
vs-keybindings	ms-	0.2.0
azurerm-vscode-tools	msa	0.4.0
vscode-docker	Pet	0.0.25

[rzulkoski]

I have the same issue. How are we expected to provide input values to azure-pipelines-task-lib when debugging?

[vscodebot]

We closed this issue because we are unable to reproduce the problem with the steps you describe. Chances are we've already fixed your problem in a recent version of VS Code. If not, please ask us to reopen the issue and provide us with more detail. Our issue reporting guidelines might help you with that.

Happy Coding!

[weinand]

As you can see in the following screenshot this works fine for me in VS Code 1.30 (Stable):

[rzulkoski]

@weinand Sorry I should have been more specific. @BenLBartle mentioned in his original post that the vsts-task-lib (now azure-devops-task-lib) expects input values to be prefixed with "INPUT_".

Can you retry running that same example but renaming "INVALID_VALUE" to "INPUT_VALUE" or something that similarly starts with "INPUT_"? I think you will find that it is undefined.

[weinand]

Sorry, but I see no difference:

[weinand]

What version of node.js are you using?

[rzulkoski]

@weinand Thanks for helping, I think I've figured out the issue. I'm going to list my findings below for the benefit of others. Feel free to close this issue.

If you use the azure-pipelines-task-lib you may notice that any node environment variables starting with "INPUT_" are not present on process.env when debugging. That is because in the _loadData() method in internal.ts the value of the input is stored in the internal vault and then removed from the environment. The value can be retrieved from the vault using the task library's getInput(name) method like so:

import * as tl from 'azure-pipelines-task-lib/task';

let myInput = tl.getInput('VALUE');

I incorrectly assumed that it would still be present in process.env.

Hope this helps somebody along the way!

[weinand]

@rzulkoski great finding and thanks a lot for documenting this here.

[rzulkoski]

@weinand no problem, happy to!

A few more notes as my problem wasn't completely solved until now:

I was modeling my project after the vsts-extension-build-release-tasks repo. This repo contains a BuildTasks directory at the root of the repo, which contains the individual task directories as well as a Common directory. Each subdirectory has its own package.json referencing its own dependencies, and the package.json at the root of the directory includes some scripts for running npm install on each directory.

The problem I encountered was when I referenced common.ts from one of my tasks while debugging locally, the Common/node_modules/azure-pipelines-task-lib would be hit first and would store my input in its vault and then remove it from the node environment. Then in my task when I would attempt to access that value using tl.getInput('VALUE') it would use MyTask/node_modules/azure-pipelines-task-lib where the vault is undefined because the input was already removed from the node environment.

My workaround was to remove BuildTasks/Common/package.json and add BuildTasks/package.json and make sure that individual tasks did not also include azure-pipelines-task-lib. Node's non-reference module resolution would then look for the dependencies in my task's node_modules, not find it and then look at the parent directory where it would find it. This solved the problem for debugging, but created a problem when trying to use the tasks after publishing the extension, since the common node_modules wouldn't be included in the individual task.

So I added the following scripts to my root package.json:

"copy:common:node_modules": "glob-exec --parallel --foreach \"BuildTasks/*/task.json\" -- \"cp -R BuildTasks/node_modules {{file.dir}}/lib/node_modules\"",
"build:prod": "npm run build && npm run copy:common:node_modules"

I then make sure to use npm run build:prod when building and packaging the extension.