Как запустить gulp консоль в vs code
Перейти к содержимому

Как запустить gulp консоль в vs code

  • автор:

�� Как запустить Gulp в VS Code: Подробное руководство для начинающих

После успешной установки Gulp, вы можете создать файл gulpfile.js в корне вашего проекта и добавить задачи Gulp. Например, чтобы запустить задачу ‘default’, добавьте следующий код в файл gulpfile.js:

 const gulp = require('gulp'); gulp.task('default', function() < // Ваш код для задачи 'default' здесь >); 

После сохранения файла gulpfile.js, вы можете запустить задачу ‘default’ выполнив команду:

 gulp 

Детальный ответ

Как запустить Gulp в Visual Studio Code

Если вы разрабатываете веб-приложения, вероятно, вам приходилось сталкиваться с большим объемом кода JavaScript и CSS. Возможно, вы хотите автоматизировать процесс сборки, тестирования и развертывания вашего проекта. В этом случае Gulp — отличный выбор.

Gulp — это инструмент сборки для автоматизации различных задач веб-разработки. Он позволяет обрабатывать и объединять файлы, сжимать изображения, компилировать препроцессоры CSS и многое другое. Теперь давайте посмотрим, как запустить Gulp в Visual Studio Code.

Шаг 1: Установка Gulp

Прежде чем начать использовать Gulp, у вас должен быть установлен Node.js и npm (Node Package Manager). Если они уже установлены, вы можете перейти к следующему шагу. Если нет, вы должны их установить с официального сайта Node.js.

Шаг 2: Создание проекта

Перейдите в папку вашего проекта с помощью команды cd /path/to/your/project . Затем выполните следующую команду для инициализации проекта:

npm init

Это создаст файл package.json, в котором будут храниться настройки и зависимости вашего проекта.

Шаг 3: Установка Gulp локально

После создания проекта вы можете установить Gulp локально с помощью следующей команды:

npm install gulp --save-dev

Ключ —save-dev гарантирует, что Gulp будет установлен как зависимость разработки в вашем проекте. Он будет указан в файле package.json.

Шаг 4: Создание Gulpfile.js

Создайте файл с именем Gulpfile.js в корневой папке вашего проекта. В этом файле будут храниться задачи Gulp и их настройки.

Вот пример простого Gulpfile.js:

const gulp = require('gulp'); gulp.task('hello', function() < console.log('Привет, мир!'); >);

Шаг 5: Запуск задачи Gulp

Теперь, когда у вас есть Gulpfile.js и установлен Gulp, вы готовы запустить свою первую задачу Gulp. Введите следующую команду в терминале Visual Studio Code в директории вашего проекта:

gulp hello

Результат выполнения задачи будет отображен в консоли.

Шаг 6: Добавление дополнительных плагинов Gulp

Gulp предлагает широкий выбор плагинов для обработки различных типов файлов и выполнения различных задач. Например, вы можете добавить плагин для сборки и минификации CSS файлов, компиляции препроцессоров и многое другое.

Чтобы установить плагин Gulp, используйте команду npm install имя-плагина —save-dev . Затем добавьте плагин в Gulpfile.js и настройте соответствующую задачу.

Шаг 7: Использование Gulp с помощью плагина Gulp Tasks

Чтобы использовать Gulp в Visual Studio Code, существует удобное расширение с названием Gulp Tasks. Оно позволяет запускать задачи Gulp прямо из редактора кода.

Следуйте инструкциям для установки и настройки Gulp Tasks в Visual Studio Code. После этого вы сможете запускать задачи Gulp одним нажатием клавиши.

Заключение

Теперь вы знаете, как запустить Gulp в Visual Studio Code. Gulp может значительно упростить ваш рабочий процесс, автоматизируя множество рутинных задач веб-разработки. Начните экспериментировать с Gulp, добавляйте плагины и настроивайте свои собственные задачи. Удачи в ваших проектах!

How to run gulp task in visual studio code?

How exactly do you run the tasks from CMD? I can’t get it to work — neither in VS Code nor in PowerShell. What do you type precisely to execute a task? I have gulp installed both locally and globally.

Nov 16, 2016 at 8:40

1 Answer 1

Normally VS code auto detect gulp task.

As you can see in this doc

Pressing F1 and then typing Run Task followed by Enter will list all available tasks. Selecting one and pressing Enter will execute the task.

hope this helps

answered Apr 30, 2016 at 22:52
1,889 14 14 silver badges 23 23 bronze badges

I’m doing what you mentioned but in my version (1.7.1) there’s no Gulp tasks being listed at all. The gulpfile.js looks like this and is placed in the root, as just as described in the question. I have gulp installed both locally and globally. What can I be doing wrong? How can I troubleshoot it? I.e. how do I verify that I can run the tasks from PowerShell directly? Etc.

Nov 16, 2016 at 8:39

I’m running into the same issue. I have gulp installed via npm, deleted the tasks.json file, and when I press F1 to run task, VSCode does not detect Gulp. Has anyone ran into this issue?

��Как настроить Gulp в VS Code: подробная инструкция для новичков

Чтобы настроить Gulp в VS Code, выполните следующие шаги: 1. Установите Gulp глобально, запустив команду в терминале:

npm install gulp-cli -g

2. В вашем проекте установите Gulp локально, запустив команду в терминале:

npm install gulp --save-dev

3. Создайте файл `gulpfile.js` в корне вашего проекта. 4. В `gulpfile.js` импортируйте Gulp и описывайте ваши задачи:

const gulp = require('gulp'); gulp.task('taskName', function() < // Ваш код для задачи >); // Другие задачи. 

5. Добавьте скрипты в секцию `scripts` вашего файла `package.json`:

"scripts":

6. Теперь вы можете запускать ваши задачи Gulp, выполнив следующую команду в терминале:

npm run gulp

Удачи с использованием Gulp в VS Code!

Детальный ответ

Как настроить gulp в VS Code

Вы уже знакомы с Gulp, и теперь вы хотите настроить его в своей среде разработки VS Code. Ниже мы рассмотрим пошаговую инструкцию для настройки Gulp в VS Code.

Шаг 1: Установка Gulp

Первым шагом является установка Gulp глобально на вашей машине, если вы этого еще не сделали. Для этого откройте командную строку и выполните следующую команду:

npm install gulp-cli -g

Эта команда установит Gulp Command Line Interface (CLI) глобально, что позволит вам запускать Gulp команды из любой директории.

Шаг 2: Создание проекта

Теперь давайте создадим новый проект и настроим его для использования Gulp. В открывшейся командной строке выполните следующую команду:

mkdir my-gulp-project

Затем перейдите в созданную директорию:

cd my-gulp-project

Инициализируйте проект при помощи npm:

npm init -y

Это создаст файл package.json, в котором будут храниться зависимости вашего проекта.

Шаг 3: Установка зависимостей

Теперь установим необходимые зависимости для работы с Gulp. Выполните следующую команду:

npm install gulp --save-dev

Эта команда установит Gulp в качестве зависимости разработки вашего проекта и добавит его в файл package.json.

Шаг 4: Создание gulpfile.js

Теперь создадим файл gulpfile.js, который будет содержать задачи для Gulp. Создайте новый файл с именем gulpfile.js в корневой директории вашего проекта и откройте его в текстовом редакторе. В gulpfile.js вы можете определить различные задачи, такие как компиляция и сборка файлов, запуск локального сервера, минификация и т.д. Давайте определим простую задачу, которая будет выводить сообщение в консоль:

const gulp = require('gulp'); gulp.task('message', function() < console.log('Привет, Gulp!'); >); gulp.task('default', gulp.series('message'));

Сохраните файл gulpfile.js после добавления кода.

Шаг 5: Запуск задачи Gulp

Теперь, когда у нас есть настроенный gulpfile.js, давайте запустим нашу задачу Gulp. В командной строке выполните следующую команду:

gulp

Вы увидите результат выполнения задачи в консоли:

[10:32:44] Using gulpfile ~/my-gulp-project/gulpfile.js [10:32:44] Starting 'message'. Привет, Gulp! [10:32:44] Finished 'message'

Готово! Вы успешно настроили Gulp в своей среде разработки VS Code.

Заключение

Настройка Gulp в VS Code несложна, и с помощью этой статьи вы сможете быстро начать использовать Gulp для автоматизации ваших рабочих процессов. Однако, помимо приведенных выше шагов, Gulp предлагает множество других функций и плагинов, которые могут вам пригодиться. Рекомендуем ознакомиться с официальной документацией Gulp для более глубоких и продвинутых функций.

Как запустить gulp консоль в vs code

Вообще, эти инструменты настолько хороши, что грядущий релиз ASP.NET отказался от своей фирменной комплектации и диспетчеров задач в пользу широко используемых обществом инструментов. А теперь они являются главными элементами в Visual Studio и Visual Studio Code. Сегодня я покажу вам как использовать Gulp в Visual Studio Code, чтобы запустить следующие наиболее часто используемые задачи:

  • Компиляция TypeScript в JavaScript
  • Компиляция SCSS-файла в чистый CSS
  • БОНУС — Добавление пары заданий для автоматического создания JS и CSS при изменения кода

Хотя Gulp является автономным инструментом, VS Code имеет отличную внешнюю поддержку для него. Это означает, что до тех пор, пока у вас есть gulpfile.js в корневом каталоге вашего проекта, VS-код будет использовать его для создания задач, доступных в IDE. Давайте начнем:

Создание проекта

Я предполагаю, что вы уже установили TypeScript и VSCode. Если нет, посмотрите здесь. Для создания проекта выберите нужное местоположение и создайте новый каталог по имени VSGulpTest .

Инсталляция npm и Gulp

Начнем с начала. Npm — менеджер пакетов Node (отсюда и название) и для того, чтобы получить его вам нужно установить Node.js. Это можно сделать двумя способами:

  1. с помощью chocalateyNuget choco install nodejs
  2. с помощью исполняемого файла, скаченного с официального сайта

Теперь нам ничто не мешает установить Gulp. Наберите в командной строке Node.js следующее: npm install —global gulp и нажмите клавишу Enter для выполнения. Эта команда устанавливает Gulp глобально. Я cтараюсь избежать глобальных установок, но, установленный локально, Gulp не будет работать в Visual Studio Code. Все остальные пакеты будут установлены локально.

Далее, нам необходимо инициализировать npm на текущем проекте. Для этого откройте командную строку Node.js, перейдите в корневой каталог вашего проекта и выполните следующую команду: npm init

В результате в корневом каталоге вашего проекта будет создан файл package.json. Этот файл используется Node.js для отслеживания установленных пакетов. Командная строка проведет вас через последовательность вопросов (Wizard CLI) для того, чтобы сгенерировать параметры конфигурации. Ни один из этих параметров не является особенно важным, вы можете оставить все из них пустыми, или скопировать мои настройки. На последнем шаге просто наберите yes для создания файла.

Установка необходимых пакетов

Gulp – это простой диспетчер задач, поэтому сам по себе он особо пользы не несет. Нам нужны плагины, чтобы помочь нам выполнить доставленные задачи, а именно: typescript, merge и sass. Чтобы установить плагины, вернитесь к командной строке Node.js, перейдите в корневой каталог вашего проекта, а затем выполните следующие команды, по одной за раз:

Эти команды будут устанавливать необходимые плагины и ряд зависимостей. Эти плагины будут вызываться из Gulp для выполнения наших задач.

Добавляем код

Прямо сейчас наш проект пуст. Давайте добавим пару TypeScript файлов, файл Sass и HTML-файл, чтобы сделать набросок сайта. Создайте файлы animal.ts и human.ts и вставьте соответствующий код.

Создайте файл main.scss для CSS кода и файл index.html для главной страницы сайта. И снова используйте код ниже, или добавьте свой собственный код в соответствующие файлы.

Добавляем Gulp-таски

Пришло время соединить все вместе и получить рабочий сайт. В корневом каталоге вашего проекта создайте файл gulpfile.js и добавьте следующий код:

Я постараюсь кратко объяснить, что происходит в этом файле. В верхней части файла мы импортируем все плагины, после чего создаем 3 задачи:

scripts компилит *.ts файлы в *.js, объединяет весь код в один файл, генерирует файлы (.d.ts) и сохраняет созданные файлы в указанном месте ( release ) sass компилит *.scss файлы в *.css и помещает созданный файл в указанном месте ( css ) watch мониторит изменение файлов *.scss и *.ts на наличие каких-либо изменений и автоматически выполняет соответствующую задачу

Теперь мы почти готовы к запуску. Находясь в Visual Studio Code, нажмите клавиши Ctrl+Shift+B для определения нового диспетчера задач.

Нажмите на Настроить средство выполнения задач. Это выведет файл tasks.json. Удалите все, что в нем есть и добавьте следующий код:

Этот код дает указание Visual Studio Code использовать Gulp в качестве главного диспетчера задач, а внутри мы объявляем 3 задачи, которые мы хотим сделать доступными для IDE. Они должны соответствовать задачам, определенным в файле gulpfile.js . Вы всегда можете пропустить не нужные вам задачи, но любая новая задача должна быть определена в gulpfile.js первой.

Если вы нажмете клавиши Ctrl+Shift+P и выберите Run Task (запуск задачи), перед вами будет раскрывающийся список задач, которые мы перечислили в файле tasks.json. Выберите таск watch и запустите его. Вы заметите, что Окно Вывода (Output Window) находится в фокусе, а в нижнем левом углу есть бегунок, дающий понять, что задача в данный момент активна.

Каждый раз, когда вы делаете изменения в *.scss, или *.ts файлах и сохраняете результат, будет вызываться соответствующая задача для выполнения. После этого вам нужно будет обновить страницу в браузере, чтобы увидеть как изменилась ваша страница.

Чтобы остановить задачу нажмите клавиши Ctrl+Shift+P и выберите Terminate running task (Завершить запущенную задачу). К счастью, IntelliSense запускается практически в самом начале, поэтому вручную много печатать вам не придется.

Также, вы можете установить пакет npm-livereload вместе с соответствующим плагином для браузера, который позволит вам автоматически обновлять тестируемую страницу каждый раз, когда есть изменения в отслеживаемых файлах.

Установка node + gulp для Windows 10

Установка node + gulp для Windows 10

Первым делом нужно установить платформу node js, чтобы разработчикам были доступны команды npm. Через команду npm, мы в дальнейшем установим и сам Gulp. В контексте работы с Gulp, мы будем использовать этот многофункциональный инструмент node js, как пакетный менеджер.

Установка node js

Скачиваем на сайте nodejs.org стабильную версию Node, рекомендованную для большинства пользователей. Система автоматически определит вашу операционную систему и выдаст подходящую ссылку на скачивание.

Установка node + gulp для Windows 10.

После скачивания запускаем установщик и делаем все, как на скриншотах.

Установка node + gulp для Windows 10.

Установка node + gulp для Windows 10.

Установка node + gulp для Windows 10.

Когда установщик закончит свою работу, откроется консоль и вы увидите следующее.

Установка node + gulp для Windows 10.

Как запустить консоль Windows 10 PowerShell

Работа на платформе node js ведется через npm команды, вводимые в консоль. У Windows 10 имеется встроенная консоль PowerShell, чтобы консоль запустилась, нужно зайти в папку проекта и зажав сочетание клавиш CTRL+SHIFT, выбрать из контекстного меню «Открыть окно PowerShell здесь».

Установка node + gulp для Windows 10.

Установка node + gulp для Windows 10.

Узнать версию node js

Для того чтобы убедится установился ли node js, проверяем его версию. Вводим в консоли команду node -v, если в ответ вы увидите название версии v.12.16.1, значит все в порядке. Делает такую же проверку и для npm. Команда npm -v должна вернуть номер версии 6.13.4. Все проверяемые номера версий актуальны на момент выхода этой статьи, у вас скорее всего будут уже другие номера версий.

Установка Gulp под Windows 10

Переходим на сайт gulpjs, запускаем в консоли команду npm install gulp-cli -g. Данная команда устанавливает Gulp глобально, то есть запускать его можно из любой папки на компьютере. Вроде как Gulp установился, но при проверки версии gulp -v, мы видим следующую картину. Что-то пошло не так.

Установка node + gulp для Windows 10.

Ошибка при установки Gulp

Система нам говорит (смотрим сообщение в консоли), что невозможно загрузить файл (gulp.ps1 cannot be loaded because running scripts is disabled) и предлагает почитать статью на сайте Microsoft о Политиках исполнения. Из статьи становится понятно, что политика выполнения PowerShell практикуется только на платформах Windows. Блокируется запуск скриптов с расширением .ps1. Что делать в таком случае? Меняем дефолтные настройки Windows через командную строку PowerShell.

  1. Запускаем PowerShell от имени администратора
  2. Проверяем текущие параметры для политики выполнения: Get-ExecutionPolicy -List
  3. Устанавливаем требуемый уровень (меняем политику выполнения) Set-ExecutionPolicy -Scope LocalMachine Unrestricted
  4. Проверяем версию Gulp, если после ввода gulp -v, вы видите CLI version: 2.2.0, значит установка прошла успешно.

Существенное дополнение

Если вы пишите код в редакторе VS Code, то вам вообще не нужна никакая консоль. У редактора имеется встроенный терминал, как раз для ввода различных команд. Больше не надо переключаться между отдельными вкладками, когда все в одном месте.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

Комментарии ( 0 ):

Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

Node.js debugging in VS Code

The Visual Studio Code editor has built-in debugging support for the Node.js runtime and can debug JavaScript, TypeScript, and many other languages that are transpiled into JavaScript. Setting up a project for Node.js debugging is straightforward with VS Code providing appropriate launch configuration defaults and snippets.

There are a few ways you can debug your Node.js programs in VS Code:

  • Use auto attach to debug processes you run in VS Code’s integrated terminal.
  • Use the JavaScript debug terminal, similar to using the integrated terminal.
  • Use a launch config to start your program, or attach to a process launched outside of VS Code.

Auto Attach

If the Auto Attach feature is enabled, the Node debugger automatically attaches to certain Node.js processes that have been launched from VS Code’s Integrated Terminal. To enable the feature, either use the Toggle Auto Attach command from the Command Palette ( ⇧⌘P (Windows, Linux Ctrl+Shift+P ) ) or, if it’s already activated, use the Auto Attach Status bar item.

There are three modes for auto attach, which you can select in the resulting Quick Pick and via the debug.javascript.autoAttachFilter setting:

  • smart (default) — If you execute a script outside of your node_modules folder or use a common ‘runner’ script like mocha or ts-node, the process will be debugged. You can configure the ‘runner’ script allow list using the Auto Attach Smart Pattern setting ( debug.javascript.autoAttachSmartPattern ).
  • always — All Node.js processes launched in the Integrated Terminal will be debugged.
  • onlyWithFlag — Only processes launched with the —inspect or —inspect-brk flag will be debugged.

After enabling Auto Attach, you’ll need to restart your terminal. This can be done by clicking the ⚠ icon in the top right of the terminal, or just creating a new one. Then, the debugger should attach to your program within a second:

When auto attach is on, the Auto Attach item will appear in the status bar across the bottom of the VS Code window. Clicking it allows you to change the auto attach mode, or temporarily turn it off. Temporarily turning off auto attach is useful if you’re running some one-off programs where you don’t need debugging, but you don’t want to disable the feature entirely.

Additional Configuration

Other Launch Configuration Properties

You can apply other properties normally found in launch.json to auto attach in the debug.javascript.terminalOptions setting. For example, to add node internals to your skipFiles, you could add the following to your user or workspace settings:

Auto Attach Smart Patterns

In smart Auto Attach mode, VS Code will try to attach to your code, and not attach to build tools you aren’t interested in debugging. It does this by matching the main script against a list of glob patterns. The glob patterns are configurable in the debug.javascript.autoAttachSmartPattern setting, which defaults to:

$KNOWN_TOOLS$ is replaced with a list of common ‘code runners’ such as ts-node , mocha , ava , and so on. You can modify this list if these settings don’t work. For example, to exclude mocha and include my-cool-test-runner , you could add two lines:

JavaScript Debug Terminal

In a similar way to auto attach, the JavaScript Debug Terminal will automatically debug any Node.js process you run in it. You can create a Debug Terminal by running the Debug: Create JavaScript Debug Terminal command from the Command Palette ( kbs(workbench.action.showCommands) ), or by selecting the Create JavaScript Debug Terminal from the terminal switcher dropdown.

Create Debug Terminal

Additional Configuration

Other Launch Configuration Properties

You can apply other properties normally found in launch.json to the debug terminal in the debug.javascript.terminalOptions setting. For example, to add node internals to your skipFiles, you could add the following to your user or workspace settings:

Launch Configuration

Launch configs are the traditional way to set up debugging in VS Code, and provide you the most configuration options for running complex applications.

In this section we’ll go into more detail about configurations and features for more advanced debugging scenarios. You’ll find instruction for debugging with source maps, stepping over external code, doing remote debugging, and much more.

If you’d like to watch an introductory video, see Getting started with Node.js debugging.

Note: If you are just getting started with VS Code, you can learn about general debugging features and creating launch.json configuration files in the Debugging topic.

Launch configuration attributes

Debugging configurations are stored in a launch.json file located in your workspace’s .vscode folder. An introduction into the creation and use of debugging configuration files is in the general Debugging article.

Below is a reference of common launch.json attributes specific to the Node.js debugger. You can view the complete set of options in the vscode-js-debug options documentation.

The following attributes are supported in launch configurations of type launch and attach :

  • outFiles — array of glob patterns for locating generated JavaScript files. See section Source maps.
  • resolveSourceMapLocations — an array of glob patterns for locations where source maps should be parsed. See section Source maps.
  • timeout — when restarting a session, give up after this number of milliseconds. See section Attaching to Node.js.
  • stopOnEntry — break immediately when the program launches.
  • localRoot — VS Code’s root directory. See section Remote debugging below.
  • remoteRoot — Node’s root directory. See section Remote debugging below.
  • smartStep — try to automatically step over code that doesn’t map to source files. See section Smart stepping.
  • skipFiles — automatically skip files covered by these glob patterns. See section Skipping uninteresting code.
  • trace — enable diagnostic output.

These attributes are only available for launch configurations of request type launch :

  • program — an absolute path to the Node.js program to debug.
  • args — arguments passed to the program to debug. This attribute is of type array and expects individual arguments as array elements.
  • cwd — launch the program to debug in this directory.
  • runtimeExecutable — absolute path to the runtime executable to be used. Default is node . See section Launch configuration support for ‘npm’ and other tools.
  • runtimeArgs — optional arguments passed to the runtime executable.
  • runtimeVersion — if «nvm» (or «nvm-windows») or «nvs» is used for managing Node.js versions, this attribute can be used to select a specific version of Node.js. See section Multi version support below.
  • env — optional environment variables. This attribute expects environment variables as a list of string typed key/value pairs.
  • envFile — optional path to a file containing environment variable definitions. See section Load environment variables from external file below.
  • console — the console to launch the program ( internalConsole , integratedTerminal , externalTerminal ). See section Node Console below.
  • outputCapture — if set to std , output from the process stdout/stderr will be shown in the Debug Console, instead of listening to output over the debug port. This is useful for programs or log libraries that write directly to the stdout/stderr streams instead of using console.* APIs.

This attribute is only available for launch configurations of request type attach :

  • restart — restart the connection on termination. See section Restarting debug session automatically.
  • port — debug port to use. See sections Attaching to Node.js and Remote debugging.
  • address — TCP/IP address of the debug port. See sections Attaching to Node.js and Remote debugging.
  • processId — the debugger tries to attach to this process after having sent a USR1 signal. With this setting, the debugger can attach to an already running process that was not started in debug mode. When using the processId attribute, the debug port is determined automatically based on the Node.js version (and the used protocol) and cannot be configured explicitly. So don’t specify a port attribute.
  • continueOnAttach — whether to continue the process if it’s paused when we attach to it. This option is useful if you launch your program with —inspect-brk .
Launch configurations for common scenarios

You can trigger IntelliSense ( ⌃Space (Windows, Linux Ctrl+Space ) ) in your launch.json file to see launch configuration snippets for commonly used Node.js debugging scenarios.

Launch configuration snippets for Node.js

You can also bring up the snippets with the Add Configuration. button in the lower right of the launch.json editor window.

These are the available snippets:

  • Launch Program: Launch a Node.js program in debug mode.
  • Launch via npm: Launch a Node.js program through an npm ‘debug’ script. If you have defined an npm debug script in your package.json, you can use it directly from your launch configuration. Make sure that the debug port used in the npm script, corresponds to the port specified in the snippet.
  • Attach: Attach to the debug port of a locally running Node.js program. Make sure that the Node.js program to debug has been started in debug mode, and the debug port used is the same as the one specified in the snippet.
  • Attach to Remote Program: Attach to the debug port of a Node.js program running on the host specified by the address attribute. Make sure that the Node.js program to debug has been started in debug mode, and the debug port used is the same as the one specified in the snippet. To help VS Code map source files between your workspace and the filesystem of the remote host, make sure to specify correct paths for the localRoot and remoteRoot attributes.
  • Attach by Process ID: Open the process picker to select a node or gulp process for debugging. With this launch configuration, you can even attach to a node or gulp process that was not started in debug mode.
  • Nodemon Setup: Use nodemon to relaunch a debug session automatically whenever the JavaScript source has changed. Make sure that you have nodemon installed globally. Note that terminating the debug session only terminates the program to debug, not nodemon itself. To terminate nodemon, press Ctrl+C in the Integrated Terminal.
  • Mocha Tests: Debug mocha tests in a test folder of your project. Make sure that your project has ‘mocha’ installed in its node_modules folder.
  • Yeoman generator: Debug a yeoman generator. The snippet asks you to specify the name of the generator. Make sure that your project has ‘yo’ installed in its node_modules folder and that your generated project has been installed for debugging by running npm link in the project folder.
  • Gulp task: Debug a gulp task. Make sure that your project has ‘gulp’ installed in its node_modules folder.
  • Electron Main: Debug the main Node.js process of an Electron application. The snippet assumes that the Electron executable has been installed inside the node_modules/.bin directory of the workspace.
Node console

By default, Node.js debug sessions launch the target in the internal VS Code Debug Console. Since the Debug Console does not support programs that need to read input from the console, you can enable either an external terminal or use the VS Code Integrated Terminal by setting the console attribute in your launch configuration to externalTerminal or integratedTerminal respectively. The default is internalConsole .

If an external terminal is used, you can configure which terminal program to use via the terminal.external.windowsExec , terminal.external.osxExec , and terminal.external.linuxExec settings.

Launch configuration support for ‘npm’ and other tools

Instead of launching the Node.js program directly with node, you can use ‘npm’ scripts or other task runner tools directly from a launch configuration:

  • Any program available on the PATH (for example ‘npm’, ‘mocha’, ‘gulp’, etc.) can be used for the runtimeExecutable attribute and arguments can be passed via runtimeArgs .
  • You do not have to set the program attribute if your npm script or other tool implicitly specifies the program to launch.

Let’s look at an ‘npm’ example. If your package.json has a ‘debug’ script, for example:

the corresponding launch configuration would look like this:

Multi version support

If you are using ‘nvm’ (or ‘nvm-windows’) to manage your Node.js versions, it is possible to specify a runtimeVersion attribute in a launch configuration for selecting a specific version of Node.js:

If you are using ‘nvs’ to manage your Node.js versions, it is possible to use runtimeVersion attribute to select a specific version, architecture, and flavor Node.js, for example:

Make sure to have those Node.js versions installed that you want to use with the runtimeVersion attribute, as the feature will not download and install the version automatically. For example, you’ll have to run something like nvm install 7.10.1 or nvs add 7.10.1 from the integrated terminal if you plan to add «runtimeVersion»: «7.10.1» to your launch configuration.

If you omit the minor and patch version and have, for example, «runtimeVersion»: «14» , then the most recent 14.x.y version installed on your system will be used.

Load environment variables from external file

The VS Code Node debugger supports loading environment variables from a file and passing them to the Node.js runtime. To use this feature, add an attribute envFile to your launch configuration and specify the absolute path to the file containing the environment variables:

Any environment variable specified in the env dictionary will override variables loaded from the file.

Here’s an example of an .env file:

Attaching to Node.js

If you want to attach the VS Code debugger to an external Node.js program, launch Node.js as follows:

or if the program shouldn’t start running, but must wait for the debugger to attach:

Now you have a couple options for attaching the debugger to your program:

  • Open a «process picker» that lists all potential candidate processes and let you pick one, or
  • Create an «attach» configuration that explicitly specifies all configuration options and then press F5.

Let’s go through these options in detail:

Attach to Node Process action

The Attach to Node Process command from the Command Palette ( ⇧⌘P (Windows, Linux Ctrl+Shift+P ) ) opens a Quick Pick menu that lists all potential processes that are available to the Node.js debugger:

Node.js Process picker

The individual processes listed in the picker show the debug port and process ID. Once you select your Node.js process in that list, the Node.js debugger will try to attach to it.

In addition to Node.js processes, the picker also shows other programs that were launched with one of the various forms —inspect arguments. This makes it possible to attach to Electron’s or VS Code’s helper processes.

Setting up an «Attach» configuration

This option requires more work but in contrast to the previous two options it allows you to configure various debug configuration options explicitly.

The simplest «attach» configuration looks like this:

The port 9229 is the default debug port of the —inspect and —inspect-brk options. To use a different port (for example 12345 ), add it to the options like this: —inspect=12345 and —inspect-brk=12345 and change the port attribute in the launch configuration to match.

If you want to attach to a Node.js process that hasn’t been started in debug mode, you can do this by specifying the process ID of the Node.js process as a string:

Since it is a bit laborious to repeatedly find the process ID and enter it in the launch configuration, Node debug supports a command variable PickProcess that will open the process picker (from above).

Using the PickProcess variable the launch configuration looks like this:

Stop debugging

Using the Debug: Stop action (available in the Debug toolbar or via the Command Palette) stops the debug session.

If the debug session was started in «attach» mode (and the red terminate button in the Debug toolbar shows a superimposed «plug»), pressing Stop disconnects the Node.js debugger from the debuggee that then continues execution.

If the debug session is in «launch» mode, pressing Stop does the following:

When pressing Stop for the first time, the debuggee is requested to shut down gracefully by sending a SIGINT signal. The debuggee is free to intercept this signal and clean up anything as necessary and then shut down. If there are no breakpoints (or problems) in that shutdown code, the debuggee and the debug session will terminate.

However if the debugger hits a breakpoint in the shutdown code or if the debuggee does not terminate properly by itself, then the debug session will not end. In this case, pressing Stop again will force terminate the debuggee and its child processes ( SIGKILL ).

So if you see that a debug session doesn’t end when you press the red Stop button, then press the button again to force a shutdown of the debuggee.

Note that on the Windows operating system, pressing Stop always forcibly kills the debuggee and its child processes.

Source maps

The JavaScript debugger of VS Code supports source maps that help debugging of transpiled languages, for example, TypeScript or minified/uglified JavaScript. With source maps, it’s possible to single step through or set breakpoints in the original source. If no source map exists for the original source, or if the source map is broken and cannot successfully map between the source and the generated JavaScript, then breakpoints show up as unverified (gray hollow circles).

The source map feature is controlled by the sourceMaps attribute that defaults to true . This means that the debugger always tries to use source maps (if it can find any) and as a consequence, you can even specify a source file (for example, app.ts) with the program attribute. If you need to disable source maps for some reason, you can set the sourceMaps attribute to false .

Tool Configuration

Since source maps are not always automatically created, you should make sure to configure your transpiler to create them. For example:

TypeScript

For TypeScript, you can enable sourcemaps by passing —sourceMap to tsc , or by adding «sourceMap»: true in your tsconfig.json file.

Babel

For Babel, you’ll want to set the sourceMaps option to true , or pass the —source-maps option when compiling your code.

Webpack

Webpack has numerous source map options. We recommend setting the property devtool: «source-map» in your webpack.config.js for the best fidelity of results, although you can experiment with other settings causes slowdowns in your build.

Also, if you have additional compilation steps in webpack, such as using a TypeScript loader, you’ll also want to make sure that those steps are set up to generate sourcemaps. Otherwise, the sourcemaps that webpack generates will map back to the compiled code from the loader, instead of the real sources.

Source Map Discovery

By default, VS Code will search your entire workspace, excluding node_modules , for sourcemaps. In large workspaces, this search might be slow. You can configure the locations where VS Code will search for source maps by setting the outFiles attribute in your launch.json . For example, this configuration will only discover sourcemaps for .js files in the bin folder:

Note that the outFiles should match your JavaScript files, not the source map files (which may end in .map instead of .js ).

Source Map Resolution

By default, only source maps in your outFiles will be resolved. This behavior is used to prevent dependencies from interfering with breakpoints you set. For example, if you had a file src/index.ts and a dependency had a source map that referenced webpack:///./src/index.ts , that would incorrectly resolve to your source file and could lead to surprising results.

You can configure this behavior by setting the resolveSourceMapLocations option. If set to null , every source map will be resolved. For example, this configuration will additionally allow source maps in node_modules/some-dependency to be resolved:

Smart stepping

With the smartStep attribute set to true in a launch configuration, VS Code will automatically skip ‘uninteresting code’ when stepping through code in the debugger. ‘Uninteresting code’ is code that is generated by a transpiling process but is not covered by a source map so it does not map back to the original source. This code gets in your way when stepping through source code in the debugger because it makes the debugger switch between the original source code and generated code that you are not interested in. smartStep will automatically step through code not covered by a source map until it reaches a location that is covered by a source map again.

Smart stepping is especially useful for cases like async/await downcompilation in TypeScript, where the compiler injects helper code that is not covered by a source map.

The smartStep feature only applies to JavaScript code that was generated from source and therefore has a source map. For JavaScript without sources, the smart stepping option has no effect.

JavaScript source map tips

A common issue when debugging with source maps is that you’ll set a breakpoint, and it will turn gray. If you hover the cursor over it, you’ll see the message, «Breakpoint ignored because generated code not found (source map problem?)» . What now? There are a range of issues that can lead to this. First, a quick explanation of how the Node debug adapter handles source maps.

When you set a breakpoint in app.ts , the debug adapter has to figure out the path to app.js , the transpiled version of your TypeScript file, which is what is actually running in Node. But, there is not a straightforward way to figure this out starting from the .ts file. Instead, the debug adapter uses the outFiles attribute in the launch.json to find all the transpiled .js files, and parses them for a source map, which contains the locations of its associated .ts files.

When you build your app.ts file in TypeScript with source maps enabled, it either produces an app.js.map file, or a source map inlined as a base64-encoded string in a comment at the bottom of the app.js file. To find the .ts files associated with this map, the debug adapter looks at two properties in the source map, sources , and sourceRoot . sourceRoot is optional — if present, it is prepended to each path in sources , which is an array of paths. The result is an array of absolute or relative paths to .ts files. Relative paths are resolved relative to the source map.

Finally, the debug adapter searches for the full path of app.ts in this resulting list of .ts files. If there’s a match, it has found the source map file to use when mapping app.ts to app.js . If there is no match, then it can’t bind the breakpoint, and it will turn gray.

Here are some things to try when your breakpoints turn gray:

  • While debugging, run the Debug: Diagnose Breakpoint Problems command. This command will bring up a tool that can provide hints to help you resolve any issues from the Command Palette ( ⇧⌘P (Windows, Linux Ctrl+Shift+P ) ).
  • Did you build with source maps enabled? Make sure there are .js.map files, or inlined source maps in your .js files.
  • Are the sourceRoot and sources properties in your source map correct? Can they be combined to get the correct path to the .ts file?
  • Have you opened the folder in VS Code with the incorrect case? It’s possible to open folder foo/ from the command line like code FOO in which case source maps may not be resolved correctly.
  • Try searching for help with your particular setup on Stack Overflow or by filing an issue on GitHub.
  • Try adding a debugger statement. If it breaks into the .ts file there, but breakpoints at that spot don’t bind, that is useful information to include with a GitHub issue.

Remote debugging

Note: VS Code now has universal remote development capabilities. Using the Remote Development extensions, Node.js development in remote scenarios and containers is no different than Node.js development in a local setup. This is the recommended way to remote debug Node.js programs. Check out the Getting started section and Remote tutorials to learn more.

If you are unable to use any of the Remote Development extensions to debug your Node.js program, below is a guide on how to debug a remote Node.js program from your local instance of VS Code.

The Node.js debugger supports remote debugging where you attach to a process running on a different machine, or in a container. Specify a remote host via the address attribute. For example:

By default, VS Code will stream the debugged source from the remote Node.js folder to the local VS Code and show it in a read-only editor. You can step through this code, but cannot modify it. If you want VS Code to open the editable source from your workspace instead, you can set up a mapping between the remote and local locations. A localRoot and a remoteRoot attribute can be used to map paths between a local VS Code project and a (remote) Node.js folder. This works even locally on the same system or across different operating systems. Whenever a code path needs to be converted from the remote Node.js folder to a local VS Code path, the remoteRoot path is stripped off the path and replaced by localRoot . For the reverse conversion, the localRoot path is replaced by the remoteRoot .

Access Loaded Scripts

If you need to set a breakpoint in a script that is not part of your workspace and therefore cannot be easily located and opened through normal VS Code file browsing, you can access the loaded scripts via the LOADED SCRIPTS view in the Run and Debug view:

The LOADED SCRIPTS view lets you quickly select the script by typing its name or filter the list when Enable Filter on Type is on.

Scripts are loaded into a read-only editor where you can set breakpoints. These breakpoints are remembered across debug sessions but you only have access to the script content while a debug session is running.

Restarting debug sessions automatically when source is edited

The restart attribute of a launch configuration controls whether the Node.js debugger automatically restarts after the debug session has ended. This feature is useful if you use nodemon to restart Node.js on file changes. Setting the launch configuration attribute restart to true makes the node debugger automatically try to reattach to Node.js after Node.js has terminated.

If you have started your program server.js via nodemon on the command line like this:

you can attach the VS Code debugger to it with the following launch configuration:

Alternatively you can start your program server.js via nodemon directly with a launch config and attach the VS Code debugger:

Tip: Pressing the Stop button stops the debug session and disconnects from Node.js, but nodemon (and Node.js) will continue to run. To stop nodemon, you will have to kill it from the command line (which is easily possible if you use the integratedTerminal as shown above).

Tip: In case of syntax errors, nodemon will not be able to start Node.js successfully until the error has been fixed. In this case, VS Code will continue trying to attach to Node.js but eventually give up (after 10 seconds). To avoid this, you can increase the timeout by adding a timeout attribute with a larger value (in milliseconds).

Restart frame

The Node debugger supports restarting execution at a stack frame. This can be useful in situations where you have found a problem in your source code and you want to rerun a small portion of the code with modified input values. Stopping and then restarting the full debug session can be time-consuming. The Restart Frame action allows you to reenter the current function after you have changed variables with the Set Value action:

Restart Frame won’t roll back mutation to state outside of the function, so it may not always work as expected.

Breakpoints

Conditional Breakpoints

Conditional breakpoints are breakpoints that only pause when an expression returns a truthy value. You can create one by right-clicking in the gutter beside a line number and selecting «Conditional Breakpoint»:

Logpoints

Sometimes you want to just log a message or value when code hits a certain location, rather than pausing. You can do this with logpoints. Logpoints don’t pause, but rather log a message to the Debug Console when hit. In the JavaScript debugger, you can use curly braces to interpolate expressions into the message, like current value is: .

You can create one by right-clicking in the gutter beside a line number and selecting «Logpoint». For example, this might log something like location is /usr/local :

Hit count breakpoints

The ‘hit count condition’ controls how many times a breakpoint needs to be hit before it will ‘break’ execution. You can place a hit count breakpoint by right-clicking in the gutter beside a line number, selecting «Conditional Breakpoint», and then switching to «Hit Count».

The hit count syntax supported by the Node.js debugger is either an integer or one of the operators < , , >= , % followed by an integer.

  • >10 break always after 10 hits
  • 10 same as >=10
  • %2 break on every other hit
Breakpoint validation

For performance reasons, Node.js parses the functions inside JavaScript files lazily on first access. As a consequence, breakpoints don’t work in source code areas that haven’t been seen (parsed) by Node.js.

Since this behavior is not ideal for debugging, VS Code passes the —nolazy option to Node.js automatically. This prevents the delayed parsing and ensures that breakpoints can be validated before running the code (so they no longer «jump»).

Since the —nolazy option might increase the start-up time of the debug target significantly, you can easily opt out by passing a —lazy as a runtimeArgs attribute.

When doing so, you will find that some of your breakpoints don’t «stick» to the line requested but instead «jump» for the next possible line in already-parsed code. To avoid confusion, VS Code always shows breakpoints at the location where Node.js thinks the breakpoint is. In the BREAKPOINTS section, these breakpoints are shown with an arrow between requested and actual line number:

Breakpoints View

This breakpoint validation occurs when a session starts and the breakpoints are registered with Node.js, or when a session is already running and a new breakpoint is set. In this case, the breakpoint may «jump» to a different location. After Node.js has parsed all the code (for example, by running through it), breakpoints can be easily reapplied to the requested locations with the Reapply button in the BREAKPOINTS section header. This should make the breakpoints «jump back» to the requested location.

Breakpoint Actions

Skipping uninteresting code

VS Code Node.js debugging has a feature to avoid source code that you don’t want to step through (also known as ‘Just My Code’). This feature can be enabled with the skipFiles attribute in your launch configuration. skipFiles is an array of glob patterns for script paths to skip.

For example, using:

all code in the node_modules and lib folders in your project will be skipped. The skipFiles also apply to the location shown when calling console.log and similar methods: the first non-skipped location in the stack will be shown beside the output in the Debug Console.

Built-in core modules of Node.js can be referred to by the ‘magic name’ in a glob pattern. The following example skips all internal modules:

The exact ‘skipping’ rules are as follows:

  • If you step into a skipped file, you won’t stop there — you will stop on the next executed line that is not in a skipped file.
  • If you have set the option to break on thrown exceptions, then you won’t break on exceptions thrown from skipped files unless they bubble up into a non-skipped file.
  • If you set a breakpoint in a skipped file, you will stop at that breakpoint, and you will be able to step through it until you step out of it, at which point normal skipping behavior will resume.
  • The location of console messages from inside skip files will be shown as the first non-skipped location in the call stack.

Skipped source is shown in a ‘dimmed’ style in the CALL STACK view:

Skipped source is dimmed in call stack view

Hovering over the dimmed entries explains why the stack frame is dimmed.

A context menu item on the call stack, Toggle skipping this file enables you to easily skip a file at runtime without adding it to your launch config. This option only persists for the current debugging session. You can also use it to stop skipping a file that is skipped by the skipFiles option in your launch config.

Note: The legacy protocol debugger supports negative glob patterns, but they must follow a positive pattern: positive patterns add to the set of skipped files, while negative patterns subtract from that set.

In the following ( legacy protocol-only) example all but a ‘math’ module is skipped:

Note: The legacy protocol debugger has to emulate the skipFiles feature because the V8 Debugger Protocol does not support it natively. This might result in slow stepping performance.

Supported Node-like runtimes

The current VS Code JavaScript debugger supports Node version at or above 8.x, recent Chrome versions, and recent Edge versions (via the msedge launch type).

Next steps

In case you didn’t already read the Node.js section, take a look at:

    — End to end Node scenario with a sample application

To see tutorials on the basics of Node.js debugging, check out these videos:

    — Introductory video showcasing the basics of debugging. — Learn how to attach to a running Node.js process.

To learn about VS Code’s task running support, go to:

    — Running tasks with Gulp, Grunt, and Jake. Showing Errors and Warnings

To write your own debugger extension, visit:

    — Steps to create a VS Code debug extension starting from a mock sample

Common questions

Can I debug if I’m using symlinks?

Yes, if you’ve created symlinks for folders inside your project, such as with npm link , you can debug the symlinked sources by telling the Node.js runtime to preserve symlinked paths. Use the node.exe —preserve-symlinks switch in your launch configuration runtimeArgs attribute. runtimeArgs , an array of strings, are passed to the debugging session runtime executable, which defaults to node.exe.

If your main script is inside a symlinked path, then you will also need to add the «—preserve-symlinks-main» option. This option is only available in Node 10+.

How to debug gulp tasks in Visual Studio Code — Gulp 4

I recently read an article about debugging gulp tasks in Visual Studio Code, which seemed like mana from heaven for me as I’m now working with nant, npm, gulp scripts, AngularJS and all the associated goodies as well as my comfort zone of Microsoft technologies.

Being very new to the non-Microsoft stuff, my debugging when encountering issues with build scripts consisted of adding the traditional console.log calls liberally throughout. This helps, but it’s no substitute for being able to attach a debugger, especially when you realise that you want to see what the value of another variable was/is and have to edit and re-run the build script to determine this. Unfortunately, the instructions didn’t seem to play nicely for me, spitting out the message:

For a relatively simple gulp script:

In order to fix this, we need to change the structure of the last line to (have a read of this to see why):

Alas, we’re still seeing some odd output:

This is also easily fixed by updating the definition of testTask to:

There’s a good explanation of why this is needed about a quarter of the way down this page:

Hitting F5 in Visual Studio code now gives the expected output, as well as hitting any breakpoints that have been set, like the one that I had set on the console.log line that meant that testTask took nearly 3 seconds to run:

I’ve got a little bit of work to do before I can readily debug the build scripts I have here, but I do now have a simple gulp script that runs against gulp 4 which allows breakpoints to be set in Visual Studio Code and F5 being hit to start execution. Baby steps! For completness, the content of all the files that formed part of my Visual Studio Code project is below. Setting breakpoints within gulpfile.js worked a treat for me, hopefully it does for you as well!

.vscode/launch.json
package.json
gulpfile.js
About Rob

I’ve been interested in computing since the day my Dad purchased his first business PC (an Amstrad PC 1640 for anyone interested) which introduced me to MS-DOS batch programming and BASIC.

My skillset has matured somewhat since then, which you’ll probably see from the posts here. You can read a bit more about me on the about page of the site, or check out some of the other posts on my areas of interest.

Related posts:

  1. Какой пароль от духовной сети хуа чена
  2. Как разблокировать пользователя в оракле
  3. Как чекать прокси на валид
  4. Retry timeout exceeded что означает

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *