На этой неделе я узнал, как заставить VS Code Chrome Debugger работать с веб-приложением, над которым я работаю и которое использует веб-пакет. Весь процесс был довольно простым, и работать с VS Code Chrome Debugger очень весело. Одним словом: круто.
Процесс:
- Установите отладчик для Chrome и перезагрузите рабочее пространство.
2. Откройте панель отладчика: это значок «нет ошибок» прямо над значком расширений, или вы можете нажать CMD + SHIFT + D
3. Теоретически или, может быть, на практике, если вам повезет, вы можете щелкнуть зеленую стрелку, Chrome Debugger сгенерирует для вас launch.json, и вы без проблем можете добавить точки останова в свой код. Если вам не повезло, возможно, есть несколько вещей, которые нужно решить, прежде чем вы отправитесь в путь.
4. Во-первых, в readme упоминается забавная штука с режимом удаленной отладки Chrome:
Для меня Chrome уже был запущен по двум причинам: моя конфигурация веб-пакета автоматически открывает мой сервер разработки, когда я его запускаю, и в настоящее время я читал документацию по этому расширению.
Я подумал, нет проблем, я просто настрою Chrome на постоянное включение удаленного отладчика. За исключением того, что вы не можете этого сделать (если вы работаете на Mac), вам нужно выполнить /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 в своем терминале, а именно так я никогда не хочу открывать Chrome.
К счастью, расширение Chrome Debugger решает эту проблему, запустив отдельный экземпляр Chrome с включенной удаленной отладкой. Итак, мне пришлось привыкнуть к управлению отдельным экземпляром Chrome, который я всегда запускаю через панель отладчика, но это небольшое и стоящее неудобство с точки зрения вознаграждения.
5. Отладчику Chrome необходимо знать, откуда отправляются ваши файлы, иначе он не будет знать, как останавливаться на ваших точках останова.
Взгляните на этот фрагмент из Readme:
Установите webRoot в каталог, из которого обслуживаются файлы. Мое приложение использует webpack, что означает, что мои локальные серверы запускаются с помощью webpack-dev-server, поэтому я зашел в документацию webpack-dev-server, чтобы увидеть, откуда он обслуживает мои файлы:
Немного покопавшись, я нашел то, что искал:
По умолчанию он будет использовать ваш текущий рабочий каталог для обслуживания контента…
Превосходно! В отладчике Chrome есть переменная для этого внутри launch.json с именем ${workspaceFoler}, поэтому моя конфигурация должна выглядеть так:
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8082", // or whatever port you use
"webRoot": "${workspaceFoler}"
}
Или, по крайней мере, я думал, что это сработает. За исключением того, что я выполнил рекомендацию в документации webpack для моей конфигурации webpack и установил context:
Установка контекста фактически изменяет путь для webpack-dev-server и, соответственно, расширения Chrome Debugger с ${workspaceFoler} на путь контекста, который для меня был /app (то же, что вы видите в документах выше). Итак, моя фактическая рабочая конфигурация:
{
"type": "chrome",
"request": "attach",
"name": "Attach to Chrome",
"port": 9222,
"webRoot": "${workspaceFolder}/app"
},
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8082",
"webRoot": "${workspaceFolder}/app"
}
Я также добавил действие attach, которое использует ту же конфигурацию webRoot и позволяет вам подключаться к уже запущенному сеансу (при условии, что в экземпляре Chrome включен удаленный отладчик), что полезно для перехода в сеансы отладки и выхода из них.
Успех!
После этих шагов я начал работать с Chrome Debugger для VS Code, и теперь я весело удаляю точки останова прямо в своем редакторе, как будто я какой-то Java-разработчик, использующий IntelliJ. Я очень 🎉 взволнован 🎉 💯 отладкой внутри редактора. Это значительно ускоряет мой процесс и снижает часть умственного напряжения при отладке сложных проблем. Это определенно была классная вещь, которую я узнал, и я рад ею поделиться.
