-->
- If you have JSON that you want to deserialize, and you don't have the class to deserialize it into, Visual Studio 2019 can automatically generate the class you need: Copy the JSON that you need to deserialize. Create a class file and delete the template code. Choose Edit Paste Special Paste JSON as Classes.
- All keyboard shortcuts in VS Code can be customized via the keybindings.json file. To configure keyboard shortcuts through the JSON file, open Keyboard Shortcuts editor and select the Open Keyboard Shortcuts (JSON) button on the right of the editor title bar. This will open your keybindings.json file where you can overwrite the Default Keybindings.
A Visual Studio Code extension to convert the current editor selection from JSON to CSV, and vice versa. After installation, you'll find two new commands in the Command Palette (F1 by default): Convert JSON to CSV; Convert CSV to JSON; Uses json-2-csv to do the actual conversion.
npm allows you to install and manage packages for use in your Node.js applications. Visual Studio makes it easy to interact with npm and issue npm commands through the UI or directly. If you're unfamiliar with npm and want to learn more, go to the npm documentation.
Visual Studio integration with npm is different depending on your project type.
Important
npm expects the node_modules folder and package.json in the project root. If your app's folder structure is different, you should modify your folder structure if you want to manage npm packages using Visual Studio.
Node.js projects
For Node.js projects, you can perform the following tasks:
These features work together and synchronize with the project system and the package.json file in the project.
Prerequisites
You need the Node.js development workload and the Node.js runtime installed to add npm support to your project. For detailed steps, see Create a Node.js project.
Note
For existing Node.js projects, use the From existing Node.js code solution template or the Open folder (Node.js) project type to enable npm in your project.
Install packages from Solution Explorer (Node.js)
For Node.js projects, the easiest way to install npm packages is through the npm package installation window. To access this window, right-click the npm node in the project and select Install New npm Packages.
In this window you can search for a package, specify options, and install.
- Dependency type - Chose between Standard, Development, and Optional packages. Standard specifies that the package is a runtime dependency, whereas Development specifies that the package is only required during development.
- Add to package.json - Recommended. This configurable option is deprecated.
- Selected version - Select the version of the package you want to install.
- Other npm arguments - Specify other standard npm arguments. For example, you can enter a version value such as
@~0.8to install a specific version that is not available in the versions list.
You can see the progress of the installation in the npm output in the Output window. This may take some time.
Tip
You can search for scoped packages by prepending the search query with the scope you're interested in, for example, type @types/mocha to look for TypeScript definition files for mocha. Also, when installing type definitions for TypeScript, you can specify the TypeScript version you're targeting by adding @ts2.6 in the npm argument field.
Manage installed packages in Solution Explorer (Node.js)
npm packages are shown in Solution Explorer. The entries under the npm node mimic the dependencies in the package.json file.
Package status
- - Installed and listed in package.json
- - Installed, but not explicitlylisted in package.json
- - Not installed, but listed in package.json
Right-click the npm node to take one of the following actions:
- Install New npm Packages Opens the UI to install new packages.
- Install npm Packages Runs the npm install command to install all packages listed in package.json. (Runs
npm install.) - Update npm Packages Updates packages to the latest versions, according to the semantic versioning (SemVer) range specified in package.json. (Runs
npm update --save.). SemVer ranges are typically specified using '~' or '^'. For more information, package.json configuration.
Right-click a package node to take one of the following actions:
- Install npm Package(s) Runs the npm install command to install the package version listed in package.json. (Runs
npm install.) - Update npm Package(s) Updates the package to the latest version, according to the SemVer range specified in package.json. (Run
npm update --save.) SemVer ranges are typically specified using '~' or '^'. - Uninstall npm Package(s) Uninstalls the package and removes it from package.json (Runs
npm uninstall --save.)
Right-click a package node or the npm node to take one of the following actions:
- Install missing packages that are listed in package.json
- Update npm packages to the latest version
- Uninstall a package and remove from package.json
Note
For help resolving issues with npm packages, see Troubleshooting.
Use the .npm command in the Node.js Interactive Window (Node.js)
You can also use the .npm command in the Node.js Interactive Window to executenpm commands. To open the window, right-click the project in Solution Explorer and choose Open Node.js Interactive Window.
In the window, you can use commands such as the following to install a package:
.npm install azure@4.2.3
Tip
By default, npm will execute in your project's home directory. If you have multiple projectsin your solution specify the name or the path of the project in brackets..npm [MyProjectNameOrPath] install azure@4.2.3
Tip
If your project doesn't contain a package.json file, use .npm init -y to create a new package.json filewith default entries.
ASP.NET Core projects
For projects such as ASP.NET Core projects, you can integrate npm support in your project and use npm to install packages.
Note
For ASP.NET Core projects, you can also use Library Manager or yarn instead of npm to install client-side JavaScript and CSS files.
Add npm support to a project (ASP.NET Core)
If your project does not already include a package.json file, you can add one to enable npm support by adding a package.json file to the project.
If you don't have Node.js installed, we recommend you install the LTS version from the Node.js website for best compatibility with outside frameworks and libraries.
npm requires Node.js.
To add the package.json file, right-click the project in Solution Explorer and choose Add > New Item. Choose the npm Configuration File, use the default name, and click Add.
If you don't see the npm Configuration File listed, Node.js development tools are not installed. You can use the Visual Studio Installer to add the Node.js development workload. Then repeat the previous step.
Include one or more npm packages in the
dependenciesordevDependenciessection of package.json. For example, you might add the following to the file:
Visual Studio Json Beautify
When you save the file, Visual Studio adds the package under the Dependencies / npm node in Solution Explorer. If you don't see the node, right-click package.json and choose Restore Packages.
Note
In some scenarios, Solution Explorer may not show the correct status for installed npm packages. For more information, see Troubleshooting.
Install packages using package.json (ASP.NET Core)
For projects with npm included, you can configure npm packages using package.json. Right-click the npm node in Solution Explorer and choose Open package.json.
IntelliSense in package.json helps you select a particular version of an npm package.
When you save the file, Visual Studio adds the package under the Dependencies / npm node in Solution Explorer. If you don't see the node, right-click package.json and choose Restore Packages.
It may take several minutes to install a package. Check progress on package installation by switching to npm output in the Output window.
Troubleshooting npm packages
Json Visual Studio Code
npm requires Node.js If you don't have Node.js installed, we recommend you install the LTS version from the Node.js website for best compatibility with outside frameworks and libraries.
For Node.js projects, you must have the Node.js development workload installed for npm support.
In some scenarios, Solution Explorer may not show the correct status for installed npm packages due to a known issue described here. For example, the package may appear as not installed when it is installed. In most cases, you can update Solution Explorer by deleting package.json, restarting Visual Studio, and re-adding the package.json file as described earlier in this article. Or, when installing packages, you can use the npm Output window to verify installation status.
In some ASP.NET Core scenarios, the npm node in Solution Explorer may not be visible after your build the project. To make the node visible again, right-click the project node and choose Unload Project. Then right-click the project node and choose Reload Project.
If you see any errors when building your app or transpiling TypeScript code, check for npm package incompatibilities as a potential source of errors. To help identify errors, check the npm Output window when installing the packages, as described previously in this article. For example, if one or more npm package versions has been deprecated and results in an error, you may need to install a more recent version to fix errors. For information on using package.json to control npm package versions, see package.json configuration.
A devcontainer.json file in your project tells Visual Studio Code how to access (or create) a development container with a well-defined tool and runtime stack. This container can be used to run an application or to sandbox tools, libraries, or runtimes needed for working with a codebase. It can be used with the Remote - Containers extension or GitHub Codespaces.
See Set up a folder to run in a container for more information on configuring a dev container or use the Remote-Containers: Add Development Container Configuration Files... or Codespaces: Add DevelopmentContainer Configuration Files... commands from the Command Pallette (F1) to add a wide variety of base configurations from the vscode-dev-containers repository.
devcontainer.json properties
While some devcontainer.json properties apply generally, others are only used in specific scenarios. The following table will outline the properties that apply in each situation.
| Property | Type | Description |
|---|---|---|
| Dockerfile or image | ||
image | string | Required when using an image. The name of an image in a container registry (DockerHub, Github Container Registry, Azure Container Registry) that VS Code should use to create the dev container. |
build.dockerfile / dockerFile | string | Required when using a Dockerfile. The location of a Dockerfile that defines the contents of the container. The path is relative to the devcontainer.json file. You can find a number of sample Dockerfiles for different runtimes in the vscode-dev-containers repository. |
build.context / context | string | Path that the Docker build should be run from relative to devcontainer.json. For example, a value of '..' would allow you to reference content in sibling directories. Defaults to '.'. |
build.args | Object | A set of name-value pairs containing Docker image build arguments that should be passed when building a Dockerfile. Environment and pre-defined variables may be referenced in the values. Defaults to not set. For example: 'build': { 'args': { 'MYARG': 'MYVALUE', 'MYARGFROMENVVAR': '${localEnv:VARIABLE_NAME}' } } |
build.target | string | A string that specifies a Docker image build target that should be passed when building a Dockerfile. Defaults to not set. For example: 'build': { 'target': 'development' } |
appPort | integer, string, array | In most cases, we recommend using the new forwardPorts property. This property accepts a port or array of ports that should be published locally when the container is running. Unlike forwardPorts, your application may need to listen on all interfaces (0.0.0.0) not just localhost for it to be available externally. Defaults to []. |
containerEnv | object | A set of name-value pairs that sets or overrides environment variables for the container. Environment and pre-defined variables may be referenced in the values. For example:'containerEnv': { 'MY_VARIABLE': '${localEnv:MY_VARIABLE}' }Requires the container be recreated / rebuilt to change. |
remoteEnv | object | A set of name-value pairs that sets or overrides environment variables for VS Code (or sub-processes like terminals) but not the container as a whole. Environment and pre-defined variables may be referenced in the values. Be sure Terminal > Integrated: Inherit Env is is checked in settings or the variables will not appear in the terminal. For example: 'remoteEnv': { 'PATH': '${containerEnv:PATH}:/some/other/path', 'MY_VARIABLE': '${localEnv:MY_VARIABLE}' }Updates are applied when VS Code is restarted (or the window is reloaded). |
containerUser | string | Overrides the user all operations run as inside the container. Defaults to either root or the last USER instruction in the related Dockerfile used to create the image.On Linux, the specified container user's UID/GID will be updated to match the local user's UID/GID to avoid permission problems with bind mounts (unless disabled using updateRemoteUserUID).Requires the container be recreated / rebuilt for updates to take effect. |
remoteUser | string | Overrides the user that VS Code runs as in the container (along with sub-processes like terminals, tasks, or debugging). Defaults to the containerUser.On Linux, the specified container user's UID/GID will be updated to match the local user's UID/GID to avoid permission problems with bind mounts (unless disabled using updateRemoteUserUID).Updates are applied when VS Code is restarted (or the window is reloaded), but UID/GID updates are only applied when the container is created and requires a rebuild to change. |
updateRemoteUserUID | boolean | On Linux, if containerUser or remoteUser is specified, the container user's UID/GID will be updated to match the local user's UID/GID to avoid permission problems with bind mounts. Defaults to true.Requires the container be recreated / rebuilt for updates to take effect. |
mounts | array | An array of additional mount points to add to the container when created. Each value is a string that accepts the same values as the Docker CLI --mount flag. Environment and pre-defined variables may be referenced in the value. For example:'mounts': ['source=${localWorkspaceFolder}/app-scripts,target=/usr/local/share/app-scripts,type=bind,consistency=cached']⚠️ Codespaces ignores 'bind' mounts with the exception of the Docker socket. |
workspaceMount | string | Overrides the default local mount point for the workspace when the container is created. Supports the same values as the Docker CLI --mount flag. Primarily useful for configuring remote containers or improving disk performance. Environment and pre-defined variables may be referenced in the value. For example: 'workspaceMount': 'source=${localWorkspaceFolder}/sub-folder,target=/workspace,type=bind,consistency=cached'⚠️ Not yet supported in Codespaces or when using Clone Repository in Container Volume. |
workspaceFolder | string | Sets the default path that VS Code should open when connecting to the container. Typically used in conjunction with workspaceMount. Defaults to the automatic source code mount location.⚠️ Only supported for Docker Compose in Codespaces and when using Clone Repository in Container Volume. |
runArgs | array | An array of Docker CLI arguments that should be used when running the container. Defaults to []. For example, this allows ptrace based debuggers like C++ to work in the container:'runArgs': [ '--cap-add=SYS_PTRACE', '--security-opt', 'seccomp=unconfined' ] . |
overrideCommand | boolean | Tells VS Code whether it should run /bin/sh -c 'while sleep 1000; do :; done' when starting the container instead of the container's default command. Defaults to true since the container can shut down if the default command fails. Set to false if the default command must run for the container to function properly. |
shutdownAction | enum | Indicates whether VS Code should stop the container when the VS Code window is closed / shut down. Values are none and stopContainer (default). ⚠️ Does not apply to Codespaces. |
| Docker Compose | ||
dockerComposeFile | string, array | Required. Path or an ordered list of paths to Docker Compose files relative to the devcontainer.json file. Using an array is useful when extending your Docker Compose configuration. The order of the array matters since the contents of later files can override values set in previous ones.The default .env file is picked up from the root of the project, but you can use env_file in your Docker Compose file to specify an alternate location. |
service | string | Required. The name of the service VS Code should connect to once running. |
runServices | array | An array of services in your Docker Compose configuration that should be started by VS Code. These will also be stopped when you disconnect unless 'shutdownAction' is 'none'. Defaults to all services. |
workspaceFolder | string | Sets the default path that VS Code should open when connecting to the container (which is often the path to a volume mount where the source code can be found in the container). Defaults to '/'. |
remoteEnv | object | A set of name-value pairs that sets or overrides environment variables for VS Code (or sub-processes like terminals) but not the container as a whole. Environment and pre-defined variables may be referenced in the values. Be sure Terminal > Integrated: Inherit Env is is checked in settings or the variables will not appear in the terminal. For example: 'remoteEnv': { 'PATH': '${containerEnv:PATH}:/some/other/path', 'MY_VARIABLE': '${localEnv:MY_VARIABLE}' }Updates are applied when VS Code is restarted (or the window is reloaded) |
remoteUser | string | Overrides the user that VS Code runs as in the container (along with sub-processes like terminals, tasks, or debugging). Does not change the user the container as a whole runs as (which can be set in your Docker Compose file). Defaults to the user the container as a whole is running as (often root).Updates are applied when VS Code is restarted (or the window is reloaded). |
shutdownAction | enum | Indicates whether VS Code should stop the containers when the VS Code window is closed / shut down. Values are none and stopCompose (default).⚠️ Does not apply to Codespaces. |
| General | ||
name | string | A display name for the container. |
extensions | array | An array of extension IDs that specify the extensions that should be installed inside the container when it is created. Defaults to []. |
settings | object | Adds default settings.json values into a container/machine specific settings file. |
forwardPorts | array | An array of ports that should be forwarded from inside the container to the local machine. |
portsAttributes | object | Sets default properties for specific forwarded ports. Can use a port number, range, or a regular expression. |
otherPortsAttributes | object | Configure the behavior of any ports that aren't configured using portsAttributes. |
postCreateCommand | string, array | A command string or list of command arguments to run inside the container after is created. The commands execute from the workspaceFolder in the container. Use && in a string to execute multiple commands. For example, 'yarn install' or 'apt-get update && apt-get install -y curl'. The array syntax ['yarn', 'install'] will invoke the command (in this case yarn) directly without using a shell. It fires after your source code has been mounted, so you can also run shell scripts from your source tree. For example: bash scripts/install-dev-tools.sh. Not set by default. |
postStartCommand | string, array | A command string or list of command arguments to run when the container starts (in all cases). The parameters behave exactly like postCreateCommand, but the commands execute on start rather than create. Not set by default. |
postAttachCommand | string, array | A command string or list of command arguments to run after VS Code has attached to a running container (in all cases). The parameters behave exactly like postCreateCommand, but the commands execute on attach rather than create. Not set by default. |
initializeCommand | string, array | A command string or list of command arguments to run on the host machine before the container is created. The command executes from the workspaceFolder locally. The array syntax ['yarn', 'install'] will invoke the command (in this case yarn) directly without using a shell, but supports Windows/macOS/Linux path translation. The string syntax ('yarn install') is better for simple commands.⚠️ The command is run wherever the source code is located on the host. For Codespaces, this is in the cloud. |
userEnvProbe | enum | Indicates the type of shell VS Code should use to 'probe' for user environment variables to use by default while debugging or running a task: none (default), interactiveShell, loginShell, or loginInteractiveShell. Interactive shells will typically include variables set in /etc/bash.bashrc and .bashrc while login shells usually include variables from these 'rc' files, /etc/profile, and .profile. The default is none, since the other modes can slow startup. |
devPort | integer | Allows you to force a specific port that the VS Code Server should use in the container. Defaults to a random, available port. |
If you've already built the container and connected to it, be sure to run Remote-Containers: Rebuild Container or Codespaces: Rebuild Container from the Command Palette (F1) to pick up the change.
Formatting string vs. array properties
The format of certain properties will vary depending on the involvement of a shell.
postCreateCommand, postStartCommand, postAttachCommand, and initializeCommand all have an array and a string type, while runArgs only has the array type. An array is passed to the OS for execution without going through a shell, whereas a string goes through a shell (it needs to be parsed into command and arguments).
Using runArgs via a typical command line, you'll need single quotes if the shell runs into parameters with spaces. However, these single quotes aren't passed on to the executable. Thus, in your devcontainer.json, you'd follow the array format and leave out the single quotes:
Rather than:
We can compare the string and the array versions of postAttachCommand as well. You can use the following string format, which will remove the single quotes as part of the shell's parsing:
By contrast, the array format will keep the single quotes and write them to standard out (you can see the output in the dev container log):
Variables in devcontainer.json
Variables can be referenced in certain string values in devcontainer.json in the following format: ${variableName}. The following is a list of available variables you can use.
| Variable | Properties | Description |
|---|---|---|
${localEnv:VARIABLE_NAME} | Any | Value of an environment variable on the host machine (in this case, called VARIABLE_NAME). Unset variables are left blank. To for example, this would set a variable to your local home folder on Linux / macOS or the user folder on Windows:'remoteEnv': { 'LOCAL_USER_PATH': '${localEnv:HOME}${localEnv:USERPROFILE}' }⚠️ For Codespaces, the host is in the cloud rather than your local machine. |
${containerEnv:VARIABLE_NAME} | remoteEnv | Value of an existing environment variable inside the container once it is up and running (in this case, called VARIABLE_NAME). For example:'remoteEnv': { 'PATH': '${containerEnv:PATH}:/some/other/path' } |
${localWorkspaceFolder} | Any | Path of the local folder that was opened in VS Code (that contains .devcontainer/devcontainer.json).⚠️ Not yet supported when using Clone Repository in Container Volume. |
${containerWorkspaceFolder} | Any | The path that the workspaces files can be found in the container. |
${localWorkspaceFolderBasename} | Any | Name of the local folder that was opened in VS Code (that contains .devcontainer/devcontainer.json).⚠️ Not yet supported when using Clone Repository in Container Volume. |
${containerWorkspaceFolderBasename} | Any | Name of the folder where the workspace files can be found in the container. |
Attached container configuration reference
Attached container configuration files are similar to devcontainer.json and supports a subset of its properties.
| Property | Type | Description |
|---|---|---|
workspaceFolder | string | Sets the default path that VS Code should open when connecting to the container (which is often the path to a volume mount where the source code can be found in the container). Not set by default (an empty window is opened). |
extensions | array | An array of extension IDs that specify the extensions that should be installed inside the container when it is created. Defaults to []. |
settings | object | Adds default settings.json values into a container/machine specific settings file. |
forwardPorts | array | A list of ports that should be forwarded from inside the container to the local machine. |
remoteEnv | object | A set of name-value pairs that sets or overrides environment variables for VS Code (or sub-processes like terminals) but not the container as a whole. Environment and pre-defined variables may be referenced in the values. For example: 'remoteEnv': { 'PATH': '${containerEnv:PATH}:/some/other/path' } |
remoteUser | string | Overrides the user that VS Code runs as in the container (along with sub-processes like terminals, tasks, or debugging). Defaults to the user the container as a whole is running as (often root). |
postAttachCommand | string, array | A command string or list of command arguments to run after VS Code attaches to the container. Use && in a string to execute multiple commands. For example, 'yarn install' or 'apt-get update && apt-get install -y curl'. The array syntax ['yarn', 'install'] will invoke the command (in this case yarn) directly without using a shell. Not set by default. |
Variables in attached container configuration files
Variables can be referenced in certain string values in attached configuration files in the following format: ${variableName}. The following is a list of available variables you can use.
Visual Studio Json File
| Variable | Properties | Description |
|---|---|---|
${containerEnv:VAR_NAME} | remoteEnv | Value of an existing environment variable inside the container (in this case, VAR_NAME) once it is up and running. For example: 'remoteEnv': { 'PATH': '${containerEnv:PATH}:/some/other/path' } |