aws / aws/aws-toolkit-vscode

SAM local debug: support "envFile" attribute (dotenv)

Open
#1,461 5 comments 2 reactions 0 assignees View on GitHub
auth-credentials environment-variables feature-request
Dominant language
TypeScript
Stars
2k
Forks
807
Avg merge
10h 12m
Merged PRs (30d)
7

Description

**Is your feature request related to a problem? Please describe.**

The feature request is related to the SAM local Lambda debugging experience which leverages VS Code "launch configurations". While the local Lambda debugging experience supports the `aws` attribute for X and `environmentVariables` for other environment variables, at the moment it's not possible to specify an external file (i.e. `.env`) as a source for these variables.

This makes it impossible for these teams who include the launch/debugging configurations in their VCS to do so as this would result in the variables being shared with the rest of the team. This has implications both for security (i.e. secrets) and development experience (i.e. developer-specific values). At the moment the alternative is to not include the `launch.json` at all and have the user recreating it manually or commit an incomplete one that still requires user action to fill the missing values.

**Describe the solution you'd like**

It would be beneficial for the toolkit to support the `envFile` attribute which is a standard one according to the [VSCode debugging user guide](https://code.visualstudio.com/docs/editor/debugging).

An implementation of this attribute can be found in the Python debugger ([docs here](https://code.visualstudio.com/docs/python/debugging#_envfile)) as well as the Node.js one ([docs here](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_load-environment-variables-from-external-file)).

In regards to the compatibility with the existing `environmentVariables` attribute (called `environmentVariables` in other standard implementation) I see two possible behaviours, one similar to the Node.js implementation in which any environment variable specified in the `env` dictionary will override variables loaded from the file; and another in which the two attributes are mutually exclusive. On my end, as long as it's possible to use the file, I don't mind either of these or other behaviours.

**Describe alternatives you've considered**

At the moment, it's possible only to set environment variables via the `environmentVariables` attribute. This works as intended but implies having to hardcode the values in the `launch.json` file which, depending on the nature of these variable, makes it impossible to include the debugging configuration to version control.

**Additional context**

Popular `.gitignore` sources like [gitignore.io](https://gitignore.io) suggest that [for VSCode](https://www.toptal.com/developers/gitignore/api/vscode) it's ok to commit these configuration.

Contributor guide

Open the contributing guide

Research direction

Start at the SAM local Lambda launch-configuration handling that already processes `environmentVariables`, and compare it with VS Code's documented `envFile` support and the linked Python and Node.js debugger implementations. Done means an external dotenv file can supply variables for local debugging, with the interaction between `envFile` and `environmentVariables` defined and covered by the project's existing checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript, vscode
Domain
devtools
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.