Documentation

Topics Overview Overview Linux macOS Windows VS Code for the Web Raspberry Pi Network Additional Components Uninstall VS Code Tutorial Copilot Quickstart User Interface Personalize VS Code Install Extensions Tips and Tricks Intro Videos Overview Setup Quickstart Overview Language Models Context Tools Agents Customization Trust & Safety Overview Agents Tutorial Agents Window Planning Memory Tools Subagents Local Agents Copilot CLI Cloud Agents Third-Party Agents Overview Chat Sessions Add Context Inline Chat Review Edits Checkpoints Artifacts Panel Debug Chat Interactions Prompt Examples Overview Instructions Prompt Files Custom Agents Agent Skills Language Models MCP Hooks Plugins Context Engineering Customize AI Test-Driven Development Edit Notebooks with AI Test with AI Test Web Apps with Browser Tools Debug with AI MCP Dev Guide OpenTelemetry Monitoring Inline Suggestions Smart Actions Best Practices Security Troubleshooting FAQ Cheat Sheet Settings Reference MCP Configuration Workspace Context Display Language Layout Keyboard Shortcuts Settings Settings Sync Extension Marketplace Extension Runtime Security Themes Profiles Overview Voice Interactions Command Line Interface Telemetry Basic Editing IntelliSense Code Navigation Refactoring Snippets Overview Multi-Root Workspaces Workspace Trust Tasks Debugging Debug Configuration Testing Port Forwarding Integrated Browser Overview Quickstart Staging & Committing Branches & Worktrees Repositories & Remotes Merge Conflicts Collaborate on GitHub Troubleshooting FAQ Getting Started Tutorial Terminal Basics Terminal Profiles Shell Integration Appearance Advanced Overview Enterprise Policies AI Settings Extensions Telemetry Updates Overview JavaScript JSON HTML Emmet CSS, SCSS and Less TypeScript Markdown PowerShell C++ Java PHP Python Julia R Ruby Rust Go T-SQL C# .NET Swift Working with JavaScript Node.js Tutorial Node.js Debugging Deploy Node.js Apps Browser Debugging Angular Tutorial React Tutorial Vue Tutorial Debugging Recipes Performance Profiling Extensions Tutorial Transpiling Editing Refactoring Debugging Quick Start Tutorial Run Python Code Editing Linting Formatting Debugging Environments Testing Python Interactive Django Tutorial FastAPI Tutorial Flask Tutorial Create Containers Deploy Python Apps Python in the Web Settings Reference Getting Started Navigate and Edit Refactoring Formatting and Linting Project Management Build Tools Run and Debug Testing Spring Boot Modernizing Java Apps Application Servers Deploy Java Apps GUI Applications Extensions FAQ Intro Videos GCC on Linux GCC on Windows GCC on Windows Subsystem for Linux Clang on macOS Microsoft C++ on Windows Build with CMake CMake Tools on Linux CMake Quick Start C++ Dev Tools for Copilot Editing and Navigating Debugging Configure Debugging Refactoring Settings Reference Configure IntelliSense Configure IntelliSense for Cross-Compiling FAQ Intro Videos Get Started Navigate and Edit IntelliCode Refactoring Formatting and Linting Project Management Build Tools Package Management Run and Debug Testing FAQ Overview Node.js Python ASP.NET Core Debug Docker Compose Registries Deploy to Azure Choose a Dev Environment Customize Develop with Kubernetes Tips and Tricks Overview Jupyter Notebooks Data Science Tutorial Python Interactive Data Wrangler Quick Start Data Wrangler PyTorch Support Azure Machine Learning Manage Jupyter Kernels Jupyter Notebooks on the Web Data Science in Microsoft Fabric Foundry Toolkit Overview Foundry Toolkit Copilot Tools Create Agents Models Playground Agent Builder Agent Inspector Evaluation Tool Catalog Fine-Tuning (Automated Setup) Fine-Tuning (Project Template) Model Conversion Tracing Profiling (Windows ML) FAQ File Structure Manual Model Conversion Manual Model Conversion on GPU Setup Environment Without Foundry Toolkit Template Project Migrating from Visualizer to Agent Inspector Overview Getting Started Resources View Deployment VS Code for the Web - Azure Containers Azure Kubernetes Service Kubernetes MongoDB Remote Debugging for Node.js Overview SSH Dev Containers Windows Subsystem for Linux GitHub Codespaces VS Code Server Tunnels SSH Tutorial WSL Tutorial Tips and Tricks FAQ Overview Tutorial Attach to Container Create Dev Container Advanced Containers devcontainer.json Dev Container CLI Tips and Tricks FAQ Default Keyboard Shortcuts Default Settings Substitution Variables Tasks Schema

On this page there are 4 sections

Debug Node.js within a container

When adding Docker files to a Node.js project, tasks and launch configurations are added to enable debugging that application within a container. However, due to the large ecosystem surrounding Node.js, those tasks cannot accommodate every application framework or library, which means that some applications will require additional configuration.

Configuring the container entry point

The Container Tools extension infers the entry point of the container--that is, the command line for starting the application in a debug mode within the container--via properties of package.json. The extension first looks for the start script in the scripts object; if found and, if it starts with a node or nodejs command, it uses that to build the command line for starting the application in debug mode. If not found or, if not a recognized node command, the main property in the package.json is used. If neither is found or recognized, then you need to explicitly set the dockerRun.command property of the docker-run task used to start the container.

Some Node.js application frameworks include CLIs for managing the application and are used to start the application in the start script, which obscure the underlying node commands. In these cases, the Container Tools extension cannot infer the start command and you must explicitly configure the start command.

Example: Configuring the entry point for a Nest.js application

{ "tasks": [ { "type": "docker-run", "label": "docker-run: debug", "dependsOn": ["docker-build"], "dockerRun": { "command": "node --inspect=0.0.0.0:9229 main.js" }, "node": { "enableDebugging": true } } ] }

Automatically launching the browser to the entry page of the application

The Container Tools extension can automatically launch the browser to the entry point of the application after it has started in the debugger. This feature is enabled by default and configured via the dockerServerReadyAction object of the debug configuration in launch.json.

This feature depends on several aspects of the application:

The application must output logs to the debug console.
The application must log a "server ready" message.
The application must serve a browsable page.

While the default settings may work for an Express.js based application, other Node.js frameworks may require explicit configuration of one or more of those aspects.

Ensuring application logs are written to the debug console

This feature depends on the application writing its logs to the debug console of the attached debugger. However, not all logging frameworks write to the debug console, even when configured to use a console-based logger (as some "console" loggers actually bypass the console and write directly to stdout).

The solution varies depending on the logging framework, but it generally requires creating/adding a logger that actually writes to the console.

Example: Configuring Express applications to write to the debug console

By default, Express.js uses the debug logging module, which can bypass the console. This can be resolved by explicitly binding the log function to the console's debug() method.

{ "tasks": [ { "type": "docker-run", "label": "docker-run: debug", "dependsOn": ["docker-build"], "dockerRun": { "env": { "DEBUG": "*" } }, "node": { "enableDebugging": true } } ] }

Configuring when the application is "ready"

The extension determines the application is "ready" to receive HTTP connections when it writes a message of the form Listening on port <number> to the debug console, as Express.js does by default. If the application logs a different message, then you should set the pattern property of the dockerServerReadyAction object of the debug launch configuration to a JavaScript regular expression that matches that message. The regular expression should include a capture group that corresponds to the port on which the application is listening.

For example, suppose the application logs the following message:

{ "configurations": [ { "name": "Containers: Node.js Launch", "type": "docker", "request": "launch", "preLaunchTask": "docker-run: debug", "platform": "node", "dockerServerReadyAction": { "pattern": "Application has started on port (\\d+)" } } ] }

Note the (\\d+) capture group for the port number, and the use of \ as a JSON escape character for the backslash in the \d character class.

Configuring the application entry page

By default, the Container Tools extension will open the "main" page of the browser (however that is determined by the application). If the browser should be opened to a specific page, the uriFormat property of the dockerServerReadyAction object of the debug launch configuration should be set to a Node.js format string, with one string token that indicates where the port should be substituted.

The corresponding uriFormat in the debug launch configuration (in launch.json) to open the about.html page instead of the main page would be:

{ "configurations": [ { "name": "Containers: Node.js Launch", "type": "docker", "request": "launch", "preLaunchTask": "docker-run: debug", "platform": "node", "node": { "remoteRoot": "/usr/my-custom-location" } } ] }

Troubleshooting

Container image fails to build or start due to missing node_modules

Dockerfiles are often arranged in such a way as to optimize either image build time, image size, or both. However, not every Node.js application framework supports all of the typical Node.js Dockerfile optimizations. In particular, for some frameworks, the node_modules folder must be an immediate subfolder of the application root folder, whereas, the Container Tools extension scaffolds a Dockerfile where the node_modules folder exists at a parent or ancestor level (which is generally allowed by Node.js).

The solution is to remove that optimization from the Dockerfile: