Vscode что за папка

Должен ли я совершить это.папка vscode для управления версиями?

— Это .vscode папка предназначена для фиксации в системе управления версиями?

в новом проекте папка пуста, кроме . Какие вещи попадут в эту папку? Это специфично для машины, специфично для разработчика, как .vs папка и, таким образом, не будет зафиксирована? Или все разработчики должны совместно использовать эту папку и, следовательно, она должна быть зафиксирована?

комментария в верхней части файла .vscode/settings.json гласит:

Это, кажется, подразумевает что папка должна содержать настройки для конкретного проекта и, таким образом, быть включена в исходный код. Кроме того,этот пост на UserVoice кажется, подразумевается, что некоторые типы будут идти туда, также предполагая, что это должно быть совершено.

6 ответов:

проверить .папка vscode если вы хотите поделиться настройками, конфигурацией задач и отладкой конфигурации с командой. Я думаю, что в целом имеет смысл поделиться настройками (например, пробелами против вкладок) с командой, если вы хотите применить настройки в команде. Мы в команде VS Code разделяем настройки отладки и задачи, а также потому, что мы хотим, чтобы наша команда имела тот же набор целей отладки и задач для VS Code.

кстати, вам не нужно иметь .папка vscode в вашем проект для настройки. Вы также можете настроить параметры на уровне пользователя.

между commit/ignore есть третий умный вариант: commit с .default суффиксом.

например, вы можете добавить settings.json to .gitignore , и commit settings.json.default , так же, как это обычная практика (в моей команде) с .env файлы.

я взял этот совет из видео зафиксировать настройки редактора в системе управления версиями? by Маттиас Петтер Йоханссон

никогда не совершал .vscode/settings.json — за странным исключением search.exclude . Если вам действительно нужно, будьте очень осторожны, ставя только настройки конкретного вашего проекта, который вы хотите исполнение для других разработчиков.
для проверки, форматирования, компиляции используйте другие файлы, такие как pcakage.json , .eslint , tsconfig.json , etc
единственный .vscode, который имеет смысл включить, — это сложные конфигурации запуска для отладки.
будьте осторожны, там может быть стороннее расширение в вашей системе, которое может поместить туда личную информацию !

ответ «нет»,потому что .vscode папка предназначена для этого редактора, и вы не должны нажимать эти личные настройки на РЕПО в случае путаницы других ,поэтому вы можете добавить его в свой проект .gitignore файл для игнорирования изменений

тот же ответ, что и выше: нет.

в качестве иллюстрации рассмотрим подход, выбранный Git 2.19 (Q3 2018), который добавляет скрипт (в contrib/ ), чтобы помочь пользователям VSCode лучше работать с кодовой базой Git.

другими словами, сгенерируйте .vscode контент (если он еще не существует), не вариант это.

посмотреть совершить 12861e2,commit 2a2cdd0,совершить 5482f41,commit f2a3b68, commit 0f47f78,commit b4d991d,commit 58930fd,commit dee3382,commit 54c06c6 (30 июля 2018) by Иоганнес Schindelin ( dscho ).
(слитый Junio C Hamano— gitster — на commit 30cf191, 15 Авг 2018)

contrib : добавить скрипт для инициализации VS конфигурации кода

VS код-это a легкий, но мощный редактор исходного кода, который работает на вашем рабочем столе и доступен для Windows, macOS и Linux.
Среди других языков он поддерживает C / C++ через расширение, которое предлагает не только строить и отлаживать код, но и Intellisense, т. е. code-aware completion и подобные тонкости.

этот патч добавляет скрипт, который помогает настроить среду для эффективной работы с VS Code:просто запустите сценарий оболочки Unix contrib/vscode/init.sh , что создает соответствующие файлы и откройте папку верхнего уровня исходного кода Git в VS Code.

почему бы просто не посмотреть на практику, кроме аргументов здесь?

один из самых больших проектов, который держит .vscode Я нашел до сих пор является Mozilla Firefox. Похоже, что команда Firefox share их общие задачи.

Так что я думаю это не плохая идея, чтобы сохранить .vscode , пока вы знаете, что вы делаете.

я обновлю этот пост, когда увижу другие крупные проекты, которые делятся .vscode .

Как создать расширение Visual Studio Code

Visual Studio Code – это редактор кода от Microsoft, доступный для систем Windows, Linux и macOS. Для внедрения дополнительных функций он предлагает готовые расширения, которые вы можете установить через Visual Studio Code Marketplace. Но если вы не можете найти расширение, которое делает именно то, что вам нужно, вы можете создать необходимое расширение самостоятельно.

В этом руководстве вы узнаете, как создать свое первое расширение Visual Studio Code.

Требования

Для выполнения этого урока нужно:

Загрузить и установить последнюю версию Visual Studio Code.
Установить Node.js. Инструкции по установке зависят от дистрибутива: Mac OS, Ubuntu, CentOS, Debian.

Это руководство было проверено на версиях Node v14.4.0, npm v6.14.5, yo v3.1.1 и generator-code v1.2.16.

1: Установка инструментов

Команда Visual Studio Code разработала специальный генератор для создания расширений. Он генерирует все необходимые стартовые файлы, чтобы вы легко могли начать создание вашего расширения.

Чтобы начать разработку расширений VS Code, вам понадобятся два пакета npm:

– интерфейс командной строки для Yeoman. – генератор Yeoman для написания расширений Visual Studio Code.

Используйте встроенный терминал Visual Studio Code, чтобы при помощи npx запустить локальные копии yo и generator-code, а затем введите команду yo code для инициализации вашего нового проекта:

npx -p yo -p generator-code yo code

После этого Yeoman запустит генератор кода.

2: Создание расширения

Теперь вы готовы начать разработку вашего первого расширения. На вашем экране вы увидите сообщение:

Сейчас вам нужно будет ответить на несколько вопросов о проекте: указать, какое расширение вы создаете, а также выбрать между TypeScript и JavaScript. В этом уроке мы выберем JavaScript.

Затем вам будет предложено еще несколько вопросов. В этом мануале мы выбрали следующие ответы:

После завершения этого процесса вы получите все файлы, необходимые для начала работы. Два самых важных файла:

package.json
extension.js

Откройте package.json и взгляните на его содержимое. Вы увидите название, описание проекта и т.п. В нем есть два очень важных раздела.

activationEvents – это список событий, которые активируют ваше расширение. Расширения загружаются по ленивой загрузке, поэтому они не активируются, пока не произойдет одно из перечисленных событий.
commands – список команд, которые пользователи смогут запускать через ваше расширение.

Мы вернемся к ним в ближайшее время.

Вы также можете просмотреть файл extension.js. В нем мы напишем код для нашего расширения. Здесь уже есть шаблонный код, давайте разберемся с ним.

В выделенной ниже строке мы регистрируем в VS Code нашу команду. Обратите внимание, что имя helloWorld совпадает с именем команды в package.json. Это не случайно. Пакет package.json определяет, какие команды доступны пользователю, но файл extension.js регистрирует код для этой команды.

В этом примере наша команда будет только отображать на экране пользователя сообщение «Hello World».

3: Отладка расширения

Теперь, когда все необходимые файлы установлены, мы можем запустить наше расширение.

Папка .vscode – это место, где VS Code хранит конфигурационные файлы проекта. В нашем случае он включает файл launch.json, содержащий конфигурации отладки.

В этом файле проводится отладка расширения. Откройте вкладку debug в левой части экрана, а затем кликните на плей.

Это откроет новый (отладочный) экземпляр VS Code.

Открыв его, вы можете развернуть палитру команд (с помощью Command + Shift + P на Mac или Ctrl + Shift + P в Windows) и запустить Hello World.

Вы увидите всплывающее сообщение «Hello World» в правом нижнем углу.

4: Редактирование расширения

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

Теоретически это событие может быть любым (что определяется символом *). Если установить для события активации значение *, то ваше расширение будет загружено при запуске VS Code.

Примечание: Этого делать не нужно, это просто комментарий.

Итак, у нас есть необходимые файлы и мы знаем, как их отлаживать. Приступим же к созданию нашего расширения. Предположим, мы хотим, чтобы это расширение создавало HTML-файл, который содержит шаблонный код и добавляется в наш проект.

Сначала давайте обновим название нашей команды. Откройте extension.js и обновите имя команды с extension.helloworld на extension.createBoilerplate.

Соответствующим образом обновите package.json:

Теперь напишем наш функционал. Первое, что нужно сделать, это потребовать пару пакетов. Мы будем использовать модули fs (file system) и path. В файл extension.js поместите:

Также нам нужно получить путь к текущей папке. Внутри раздела command поместите следующий фрагмент:

Нам также нужно присвоить шаблонный HTML-код переменной в файле extension.js, чтобы он автоматически записывался в файл. Вот этот шаблонный HTML:

Теперь нужно вызвать функцию writeFile модуля файловой системы и передать ее в пути к папке и HTML-коде.

Обратите внимание, мы используем модуль path, чтобы объединить путь к папке с именем файла, который мы хотим создать. Если внутри обратного вызова есть ошибка, мы отображаем ее пользователю. В противном случае расширение сообщает, что шаблонный файл успешно создан:

Вот как выглядит полный код extension.js:

Попробуйте выполнить отладку вашего нового расширения. Откройте палитру команд и запустите Create Boilerplate (помните, мы изменили имя).

После выполнения команды вы увидите только что созданный файл index.html и сообщение, которое уведомляет вас об этом:

Заключение

Чтобы узнать больше о том, какие API можно использовать и как именно их использовать, прочтите документацию по API от Visual Studio.

Visual Studio Code. Настройка и применение. Часть 1

Некоторое время назад перешёл на редактор кода VSCode, и в ходе изучения у меня скопился набор общих подходов и настроек, которыми было бы полезно поделиться. В данной статье затронуты все аспекты, к которым я прибегаю в ходе своей рабочей практики. Выбор редактора и его настройка — вещь глубоко субъективная, поэтому и этот гайд я решил сделать таким же персонифицированным. Здесь нет призывов к действию, практически нет и общего описания функций редактора — за этим вы можете обратиться к официальной документации, кстати хорошо написанной. Я же здесь просто последовательно пройдусь по различным аспектам применения редактора и покажу, как лично я им пользуюсь. Если после прочтения раздела вам понравится описанный в нём подход, то вы можете делать также, если же у вас уже есть сформировавшееся видение на этот счёт, то просто посмотрите на иную точку зрения. Так что тут будет много “я”, но так и задумано ��

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

В вопросе пользования редакторов ранее я пользовался Sublime Text в его стандартной комплектации, т.к. он покорил меня своими функциями редактирования с множественным курсором, которые тогда были в новинку. Потом услышал про Brackets — он был заточен специально под frontend, в нём была возможность просмотра стилей блока прямо из разметки, так называемый “peek”, и поддерживался Live Reload. Однако он был гораздо медленнее и забагованее, чем Sublime, из-за чего на нагруженных рабочих проектах вкупе со слабым железом он стал неюзабелен. Так что после него я решил опробовать Atom — в принципе, приятный редактор, но пробыл на нём недолго по той же причине — он был быстрее, но всё равно периодически намертво зависал. Ну и в итоге я вернулся обратно на Sublime— он решил все вопросы со скоростью, и на этот раз я подверг его значительной кастомизации, и с десятком расширений он преобразился. С тех пор я был ярым сублаймщиком, пока не услышал про VSCode, который стали рекомендовать респектабельные разработчики из моей области на Западе, и в различных видеокурсах, где можно видеть редактор, я стал замечать в 95% VSCode. В общем, решил дать ему шанс.

Главное преимущество VSCode заключается в том, что он быстрый, как редакторы кода (быстрее только Sublime), но при этом функциональный, как полноценная IDE. Почему я никогда не пользовался IDE — потому что они тяжеловесные и в плане интерфейса сильно нагруженные. Это противоречит всем моим представлениям о работе фронтенда. VSCode же прост внешне, похож на кастомизированный Sublime, но при этом на другом уровне функциональности, специально заточен под фронтенд и постоянно развивается (разработчики ежемесячно выкатывают апдейт с новыми фишками) — чего ещё можно желать?

Так что давайте пройдёмся по различным аспектам этого редактора, посмотрим как получить профит от его сильных сторон, и как ещё улучшить его дефолтную конфигурацию.

В рамках 1-ой части мы рассмотрим следующие аспекты работы с редактором:

Git

Палитра команд

Первое с чего стоит начать — это палитра команд (Command Palette). Это основной интерфейс, через который вы можете выполнить любую команду, определённую в рамках вашего редактора. Если вы привыкнете ею пользоваться, то это сильно ускорит ваши рабочие процессы, т.к. не нужно запоминать какая команда вызывается через какое меню или за какой комбинацией горячих клавиш спрятана. К тому же управление через одну лишь клавиатуру всегда быстрее, чем в сочетании с мышью.

Ctrl + Shift + P — вызов палитры команд.

Как часто говорят, если вы хотите запомнить только одну комбинацию, запомните Ctrl + Shift + P. Это не специфика VSCode, так было и в Sublime. Если вы забыли как вызвать некоторую команду, то просто вызовите палитру и начните вводить релативные для команды слова, после чего автосаджест выведет вам подходящие результаты.

Лично я настолько к ней привык, что не пользуюсь классическим меню в верхнем левом углу экрана и не растрачиваю собственную оперативную память на запоминание местонахождения отдельных команд — просто Ctrl + Shif + P, начинаю вводить, что мне нужно, и стрелками докручиваю до нужной команды.

Единый интерфейс

В VSCode существует ряд комбинаций клавиш, которые вызывают тот же интерфейс, но с другим флагом в начале. Т.е. сама палитра идёт с флагом “>”, а могут быть и другие или вовсе не быть. Важно понимать, что это всё единый интерфейс, так что нет необходимости запоминать все эти комбинации, если вы не пользуетесь ими активно — достаточно запомнить одну комбинацию, этот интерфейс открывающую.

Ctrl + P — открытие командной строки без флагов.

Без флага интерфейс функционирует, как открытие файлов. При этом отображается подсказка, что можно ввести “?”, чтобы увидеть список флагов, которые можно прописать, и какой функционал этот ввод предоставит.

Лично я для набора команд пользуюсь комбинацией Ctrl + Shift + P, т.к. ей пользуешься максимально часто, и в конечном счёте, это быстрее, чем прожать Ctrl + P и ввести флаг “>”. Для всего остального же использую Ctrl + P, который откроет строку без флагов, и я смогу ввести нужный, или обратиться к справке, если вдруг запамятовал.

Открытие файлов

Теперь поговорим поподробнее о самих командах. Первое и главное — это конечно же сам быстрый переход по файлам.

Последнее время стараюсь отучить себя от переключения между файлами через проводник. Практика показывает, что через командную строку получается куда быстрее. К тому же экономится место экрана, т.к. не нужно держать панель управления постоянно открытой, да и вообще это круто ��

Рядовой кейс: прописываешь стили, видишь переменную, далее, чтобы вспомнить, что она означает, заходишь в панель управления, ищешь среди кучи открытых директорий директорию со стилями и среди всех файлов скроллишь до variables.css — успех. Через командную строку: Ctrl + P, “var”, файл уже на верхней строчке списка автосаджеста, Enter — готово.

Также когда практиковался с подобной навигацией, пришёл к мысли, что часто бывает нужно открыть сразу несколько файлов, но с этим есть 2 проблемы: выбор на Enter закрывает командную строку и файл открывается в режиме на просмотр. Т.е. для выбора следующего файла нам нужно дважды кликнуть по табу открытого файла, чтобы он зафиксировался и не заменился при открытии следующего, после чего повторить последовательность выполненных операций. Оказалось, что всё это легко решается — просто нужно вместо Enter использовать стрелку вправо. Т.о., допустим, нам нужно открыть 3 файла: block.js, block.hbs и block.css. Прожимаем Ctrl + P, “block”, стрелка вправо, (стрелка вниз + стрелка вправо) x2 — получаем 3 файла, открытые на редактирование.

Прочие команды

Остальными командами я пользуюсь редко. Самое полезное, что там есть — это навигация по символам файла (@), но с введением системы хлебных крошек (об этом далее) необходимость в этом исчезла. Поиск по символам рабочей директории (#) у меня работает криво, и для навигации по коду есть куда более удобные механизмы (о навигации также позже). Ну а переходу к строке файла (:) и вовсе сложно придумать применение кроме как в целях поддержки accessibility, к тому же он и так доступен из статус бара.

Управление настройками

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

Окно настроек

Настройки прописываются через json-файлы, но также доступен и пользовательский интерфейс (UI).

Ctrl + , — переход в окно настроек.

Я обычно пользуюсь UI, но периодически бывает нужно перейти непосредственно к json-файлам. Это можно сделать нажатием по кнопке Open settings (JSON) в верхнем правом углу. Также периодически будут встречаться настройки, задающиеся в свободном формате, которые определяются только через json — в таких случаях кнопка Edit in settings.json будет присутствовать прямо в настройках этого параметра.

Настройки делятся на 3 типа:

Default User Settings — стандартные настройки. Здесь определяются дефолтные значения для всех возможных настроек редактора. Они доступны только в режиме на чтение, т.е. не переопределяются.
User Settings — пользовательские настройки. Здесь прописываются все глобально переопределяемые стандартные значения.
Workspace Settings — настройки рабочей директории. Те же пользовательские настройки, только не глобальные, а на уровне отдельного проекта.

При работе с JSON удобнее всего находить нужный параметр поиском по Default User Settings. После чего нажимаете кнопку Edit на полях и копируете данный параметр в список своих настроек. В случае с предопределённым списком возможных значений можно сразу выбрать нужное. Кроме того при ручном написании в User Settings Intellisense выведет список возможных значений в процессе набора.

⚠️ Ранее при редактировании настроек в формате JSON панель Default User Settings выводилась всегда в левом сплите. В новых версиях она отключена по умолчанию, но её можно активировать через настройку:

Общие настройки

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

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

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

Включаем перенос строк при достижения границ рабочей области экрана, чтобы не возникало горизонтальной прокрутки:

Убираем алерты с предупреждениями при удалении и перетаскивании файлов и директорий:

После того, как настройки заданы, вы думаете: “Вот другое дело, теперь заживём! Только нужно не забыть ещё и на офисном компе это повторить. Отмечу себе.”. И действительно, что если вы параллельно работаете на домашней стационарной ЭВМ, на офисном компьютере и рабочем ноутбуке? Нужно по 3 раза проделывать одну и ту же работу? Кроме того, что это тратит ваше время, рано или поздно это приведёт к различиям между настройками на различных устройствах. К счастью, для решения этой проблемы был создан плагин Settings Sync.

Settings Sync

Данный плагин позволяет создать единый хаб для ваших настроек. После того, как на одной машине были прописаны новые настройки, жмёте Upload settings, а при начале работы на других устройствах прожимаете Download settings. Быстро, просто, и ваши настройки всегда синхронизированы. При этом синхронизируются не только стандартные файлы с настройками, но и список установленных расширений, настройки рабочих директорий (папка .vscode в корне проекта), сниппеты, горячие клавиши — в общем, всё, что может быть синхронизировано.

Пошаговая инструкция по первоначальной настройке синхронизации приведена на странице плагина, так что не буду повторяться. В общих словах, нужно создать новый access token на Github и загрузить настройки, после чего система выдаст вам Gist ID, который нужно будет указать при скачивании настроек с другого устройства. Если что, этот ID сохраняется в User Settings, где его всегда можно посмотреть.

По умолчанию настройки приватные, но можно создать и публичную версию. Так можно задать корпоративные настройки, которые новоприбывшие сотрудники при настройке рабочего места при желании, если хотят пользоваться VSCode, могут себе загрузить в качестве быстрого старта, а потом уже изменять под свои нужды. При этом эти публичные настройки доступны только на чтение, так что никто кроме вас, их изменить не сможет.

Касательно загрузки / отгрузки настроек, я это делаю через палитру команд: Sync: Update / Upload Settings и Sync: Download Settings. Имеется возможность автоматизировать эти процессы, проставив соответствующие флаги в настройках, но по мне это избыточно, т.к. делается не так уж и часто, а подобная автоматизация увеличивает общее время загрузки редактора.

☝️ При работе с Settings Sync есть довольно неочевидный момент: как не синхронизировать ряд настроек из списка? Допустим, у меня дома стоит геймерский 2K-монитор и на нём шрифт в 14px смотрится хорошо, но на небольшом рабочем ноуте 13px будет в самый раз. На самом деле всё очень просто (после того как убьёшь порядком времени на поиск решения) — такие настройки нужно предварять директивой sync-ignore:

Управление рабочим пространством

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

Самое явное, что здесь можно сделать — это отказаться от панели управления. Если вы привыкнете к палитре команд, то панель вы будете разворачивать только в ряде частных случаев, а потом продолжите работать внутри.

Ctrl + B — переключение видимости панели управления.

Держать снизу панель открытой также не нужно. Terminal при работе с кодом не нужен, Debug Console нужна только при отладке, Output и Problems также открываются лишь периодически.

Ctrl + ` — переключение видимости терминала.

Если нужно выиграть пространство, то подойдёт также переход в фулскрин. Это откроет редактор на весь экран и спрячет верхнюю строку меню, которая и так не нужна. Я обычно этой функцией не пользуюсь, но если, допустим, показываешь презентацию с ноутбука с увеличенным шрифтом, то бывает полезно.

F11 — полноэкранный режим.

Тогда сразу оговорюсь о зуме. Чтобы он работал на колёсико мыши, нужно активировать его в настройках:

После этого зум станет доступен через привычные:

Ctrl + (Mouse wheel) — переключение масштаба.

Ну и последнее, Zen Mode. Если вы хотите абстрагироваться от всего кроме кода, убрать все отвлекающие факторы, то включайте этот режим. Он оставит только центрированное окно редактора и ничего более. Я включаю его периодически вечерами, когда концентрация уже понижена, ну или когда просто усердно работаю с некоторым фрагментом кода, и больше не хочу ничего видеть. Для переключения между файлами вам здесь уже придётся пользоваться Ctrl + P. Ну а чтобы выйти просто нажмите Esc.

Ctrl + K, Z — Zen mode.

Сворачивание групп

Порой на загруженных файлах бывает желание свернуть все группы. Чтобы не делать это вручную, можно свернуть сразу все. Это можно сделать через команду Fold All или через комбинацию:

Ctrl + K Ctrl + 0 — сворачивание всех раскрываемых блоков.

После того, как разберётесь со структурой, возвращаем всё обратно аналогично через Unfold All или через комбинацию:

Ctrl + K Ctrl + J — раскрытие всех раскрываемых блоков.

С добавлением хлебных крошек в этом стало меньше смысла, но стоит указать, что такая возможность имеется, т.к. изредка я ей всё-таки пользуюсь.

Написание кода

Теперь сконцентрируемся на главной функции редактора кода — непосредственно написании кода. В VSCode присутствует ряд возможностей для упрощения этого процесса.

Emmet

Emmet встроен в VSCode, его можно увидеть в списке плагинов в категории Built-in Extensions. Если кто не пользовался им ранее, то это инструмент, позволяющий упростить написание разметки. Можно сказать, что это сниппеты для HTML, только с возможностью чейнинга. Например можно написать:

Нажать Tab и получить:

Если вы знаете как пишутся CSS-селекторы, то с написанием сокращений под Emmet у вас не возникнет проблем. В данном примере к специфике Emmet относится только знак “*”, повторяющий блок указанное число раз, “$”, вставляющий счётчик, и опускание “li”, т.к. Emmet понимает это из контекста.

Если говорить об общих рекомендациях по применению, то я не советую использовать Emmet для блоков кода сложнее этого, т.к. на практике, допустим, для таблицы проще и быстрее написать thead, развернуть получившийся блок, после чего отдельно прописать tbody. Нет смысла писать всю таблицу одной строкой, т.к. вы начинаете тратить время на продумывание того, как это написать на Emmet, что противоречит изначальному смыслу его применения. Как следствие, я не использую оператор возвращения на предыдущий уровень “^” и очень редко использую оператор соседства “+”, т.к. в этих случаях проще развернуть то, что есть, и, не заморачиваясь, написать следующую часть с нуля.

Emmet также можно использовать с CSS, но лично я им при написании стилей не пользуюсь, т.к. мне хватает автосаджеста. К тому же нужно запоминать сокращения в отличие от HTML, где построение сокращений естественно, т.к. выводится из CSS-селекторов. Хотя я знаю, что некоторые разработчики находят эту возможность полезной. Так что для протокола пример применения в CSS:

P.S. Кстати, не используйте !important ��

Множественный курсор

VSCode поддерживает всю ту магию с множественным курсором, которой когда-то покорил меня Sublime Text. Вообще говоря, множественные курсоры проставляются на Alt + Click, но я этим не пользуюсь. Приведу примеры более практичного применения этой возможности.

Если нужно внести идентичные правки в нескольких местах файла, то разумно выделить сразу все эти места и изменять их параллельно. Для этого выделяем первое вхождение и через Ctrl + D выделяем последующие.

Ctrl + D — выбор следующего вхождения.

Можно выделить и сразу все:

Ctrl + F2 — выбор всех вхождений.

Однако, если цель — заменить имя цельной сущности в js, то лучше отдать предпочтение переименованию на F2 — она умнее, чем обычная текстовая замена, и как раз предназначена для таких целей (подробнее о символьных манипуляциях в следующей главе). Также замену можно произвести через Ctrl + H (про текстовый поиск опять же поговорим в следующей главе), но когда применяешь Ctrl + D цель всё-таки несколько другая — расположить множественные курсоры, чтобы параллельно изменять код в нескольких местах.

Пример применения: есть JSON-файл с тысячей вхождений поля “order” с различными значениями. Мы сочли, что такое поле нам больше не нужно. Соответственно, выделяем “”order”:”, Ctrl + F2, курсор проставляется в 1000 строк, End — переходим в конец выделенных строк, Shift + Home — выделяем строку, Backspace — стираем выделенный текст, Backspace — убираем пустые строки. Без множественного курсора мы бы провозились с этими правками довольно долго, а теперь же, расправившись с этой задачей like a boss, можем спокойно пойти выпить чая ��

Бывает, что у нас есть несколько идентичных строк, идущих подряд, и нам нужно в каждую из них дописать что-то ещё. Для этой цели подойдёт колоночное выделение:

Alt + Shift + (Drag mouse) — колоночное выделение.

С помощью колоночного выделения можно, например, перевести разбитые на отдельные строки 10 значений в единую строку — для этого выделяем начало всех нужных строк и прожимаем Backspace и “, “. Теперь значения идут одно за другим в одну строку через запятую.

Читать:

Какое приложение vpn скачать

Манипуляция строками

В отдельную группу выделю управление строками через Alt и стрелки. Здесь всего 2 комбинации, которые стоит запомнить.

Нажатие стрелок с зажатым Alt перемещает строку. Порой бывает удобно перенести выделенный участок, не переключаясь на мышь. По сути то же самое, что выделить блок мышью, и прожать Ctrl + X Ctrl + V, только быстрее, если привыкнуть. Если нужно перенести только одну строку, то выделять ничего не нужно, достаточно стоящего на строке курсора.

Alt + Arrow — перемещение строки.

Если повторить ту же комбинацию с зажатым Shift, строка вместо перемещения начнёт копироваться. Допустим, у вас есть некоторая строка и вам нужно размножить её до 20 вхождений, чтобы иметь базу, в которой вы будете потом вручную изменять отдельные фрагменты. Это можно сделать, выделив строку, нажав Ctrl + C, и ещё 19 раз прожав Enter и Ctrl + V. Создаёт видимость работы, конечно, но то же самое можно сделать, зажав Shift + Alt и стрелку вниз, и отпустив стрелку, когда строк станет достаточно. Вы можете возразить, что можно скопировать строку сразу с переносом, а Ctrl + V просто зажать. Ну вообще можно, да, и это уже похоже по трудозатратам на то, что мы делаем через Alt. Просто раньше я замечал за собой именно первый вариант, так что, полагаю, что он достаточно распространён.

Shift + Alt + Arrow — копирование строки.

Тип комментариев подбирается на основании языка. Для js будет применён // , для css /* */ , для html <!— —> , для hbs <> и т.д. Для написания стилей я пользуюсь PostCSS, и здесь важно, что для при этом комментарии определяются верно. В Sublime Text я ставил ассоциацию .pcss файлов c SCSS, в результате чего подсветка синтаксиса была примерно корректная, но комментарий вставлялся, как в SASS одинарный, что для PostCSS вызывало ошибку, т.к. в CSS должны быть блочные комментарии.

Лично я придерживаюсь такого стиля написания комментариев в скриптах, что выделение участка кода, который временно отключён, идёт через // , временные пометки в конце строк также идут через // , но пояснения пишутся через блочные комментарии /* */ на отдельных строках. Так можно визуально отделить “work in progress” участки кода, которые потом можно будет удалить, от вшитых сопровождающих пояснений работы блока, да и смотрятся блочные комментарии более аккуратно. Для вставки блочного комментария в VSCode предназначен шорткат:

Shift + Alt + A — вставка блочного комментария.

Для этого сначала прожимаем комбинацию, курсор сразу оказывается внутри комментария и вписываем внутрь нужный комментарий. Также можно пойти от обратного и сначала прописать текст комментария, потом выделить написанный текст и прожать комбинацию. В отличие от строчных комментариев здесь нужно уже выделить полную область. Со строчными можно ничего не выделять, если речь идёт об одной строке, либо небрежно затронуть нужные строки для многострочного комментирования.

Навигация по проекту

Важной частью любого редактора является его возможность навигации по файлу и проекту. Рассмотрим, что предлагает VSCode.

Текстовый поиск

В плане текстового поиска всё стандартно: есть локальный поиск по файлу и глобальный по всему проекту.

Поиск по файлам

За поиск и замену отвечает единый интерфейс, в нём доступен ввод регулярных выражений и учёт регистра.

Ctrl + F — поиск в файле.

Ctrl + H — замена в файле.

Поиск по проекту

Глобальному поиску предоставлена отдельная вкладка на панели управления. Интерфейс предоставляет всё то же самое, что и поиск по файлам, только кроме этого можно указать файлы для включения и исключения из поиска. Зачастую у меня там прописано “src” для общего поиска по исходникам, либо “src/**/*.js” для поиска только по нужному расширению.

Ctrl + Shift + F — поиск по проекту.

Ctrl + Shift + H — замена по проекту.

Символьный поиск

А вот теперь начинается самое интересное. VSCode поддерживает не только стандартный поиск по тексту, но и более интеллектуальный поиск по символам. Т.е. ваш код анализируется и редактор пытается предположить, что конкретно вы ищете (и обычно ему это удаётся). Если вы привыкнете к такому подходу к поиску, то ваша продуктивность значительно вырастет. Рассмотрим основные случаи, когда нужен поиск, и какое решение для таких типовых кейсов предлагает нам VSCode.

Переход к определению

Распространённая причина поиска по проекту — мы встречаем некоторую сущность и хотим понять, что она из себя представляет, т.е. перейти к её определению.

VSCode делает все основные сущности ссылками, так что имеется возможность перейти к определению, как и по любой другой ссылке, зажав Ctrl и кликнув по символу. В результате нас перекинет к определению данного символа в проекте, будь это тот же файл или другой конец рабочей директории. То же самое можно сделать, просто нажав F12:

F12 — переход к определению.

Весь функционал поиска завязан на комбинациях вокруг F12, но все эти команды также можно вызвать через контекстное меню правой кнопкой мыши (ПКМ).

Также есть возможность посмотреть определение, не покидая текущий файл — это так называемый “peek” функционал, который широко используется в Brackets.

Alt + F12 — превью определения.

Кстати, у меня была проблема с использованием этого шортката — он просто не срабатывал, хотя через контекстное меню команда выполнялась. Оказалось, что всё дело в Geforce Experience. Имейте в виду, если он у вас установлен, что его комбинация перекрывает эту, и чтобы это исправить, нужно переключить команду отображения FPS на другое сочетание клавиш.

Поиск всех вхождений

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

Для таких случаев VSCode предоставляет поиск по вхождениям, который также может вывести результат в виде превью, так и с недавних пор в отдельной вкладке панели управления.

Shift + F12 —вывод все вхождений в виде превью.

Shift + Alt + F12 —вывод все вхождений на панели управления.

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

Переименование сущности

Как развитие предыдущего кейса — это поиск вхождений с целью изменить имя сущности на всём проекте.

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

F2 — переименование символа.

Breadcrumbs

И последнее, о чём нужно поговорить на тему навигации — это механизм хлебных крошек.

Для начала их нужно включить, т.к. по умолчанию они выключены:

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

Представим типовой случай: у нас есть комплексный блок вроде карточки товара, мы правим его стили. Блок построен по БЭМ, у него куча разных модификаторов и вложенностей, для написания которых используется PostCSS с SCSS-подобным синтаксисом нестинга через &. Суммарно файл насчитывает свыше 1000 строк, мы на 758-ой. Мы видим на экране только &-value и что идёт переопределение стилей для модификатора cell, и хотим узнать что именно мы сейчас правим. Как это сделать? Обычно нужно скроллить наверх до предыдущего вложения, пока не дойдём до корня. С хлебными крошками мы просто смотрим на адресную строку и видим “product-card > __options > -value > .product-card — cell &”, и картина сразу складывается. Кстати для селекторов есть ещё один наглядный механизм определения конечной структуры — просто наведите курсор на текущий селектор, и увидите общую картину.

Далее, допустим мы поняли что именно мы правим, но хотим понять, общую структуру файла, чтобы лучше в нём ориентироваться. Для этого нам пришлось бы проходить по всем первым вложениям и сворачивать их (либо свернуть всё, а потом разбираться). С хлебными крошками мы просто кликаем по имени блока — в данном случае .product-card и видим цельную картину со всеми вложениями, которые можно раскрыть и посмотреть, что там внутри. Сам файл мы при этом не изменяем. Ну а для навигации по файлу нужно просто кликнуть в этом представлении по нужной сущности, и вас перекинет на неё. По сути это то же самое, что предоставляет палитра команд с флагом “@”, только удобнее.

В целом, 2 вещи, которые вам нужно запомнить: первое — если потерялись в файле, то просто смотрите на крошки и видите конечный путь, второе — если нужно перейти к другой сущности в файле, то жмёте по родительской сущности в крошках, видите общую структуру, выбираете нужное. Я уже привык управляться так с тяжёлыми файлами, и после этого стал тратить меньше времени на поиск в них чего-либо.

Ту же самую структуру, кстати, можно посмотреть через вкладку Outline проводника на панели управления.

Работа с проектами

Из коробки VSCode не предоставляет привычной системы работы с проектами, когда можно открывать не абстрактные папки, а единые сущности, имея постоянный доступ к их списку с быстрым переключением между ними. Имеется только достаточно мутная система воркспейсов. Так что сразу перейду к подходу, который я использую в работе. Он завязан вокруг использования плагина Project Manager.

Project Manager

Данный плагин предоставляет все те возможности, описанные выше, которых так не хватает в базовой комплектации. Логика следующая: при первичном развороте проекта мы открываем его корневую директорию через стандартный Open Folder. После чего мы сохраняем эту абстрактную папку, как проект: в палитре команд Project Manager: Save Project, даём проекту понятное имя, и проект добавляется в новую вкладку Project Manager панели управления.

Теперь мы имеем наглядное представление списка проектов и одним кликом можем перейти к нужному. Клик по проекту открывает его в текущем окне, а через контекстное меню, вызываемое через ПКМ, можно открыть его в новом окне.

Кроме того имя проекта дублируется в статус баре, так что вы всегда знаете в каком проекте сейчас находитесь. Клик по имени вызывает список проектов и по нему также можно переключиться на нужный — это даже быстрее, чем через панель управления.

В принципе, если вы ратуете за минимализм, то вкладку из панели управления можно совсем убрать — переключаться через нижний бар, а редактировать проекты через командную строку: Project Manager: Edit Projects. Эта команда откроет файл projects.json, где можно актуализировать список проектов. Лично я так и сделал. Для удаления вкладки из панели управления прописываем:

Единственное, что может останавливать от такого подхода — это то, что выбор проекта из бара всегда открывает его в текущем окне, а в большинстве случаев хотелось бы открывать проект в новом окне. Этот момент легко правится через задание следующей настройки:

Настройки проекта

Зачастую разные проекты строятся на различных стеках технологий и требуют своего подхода, а значит и своих специфичных настроек. Такие настройки прописываются внутри папки .vscode, в корневой директории вашего проекта. Эта папка создаётся автоматически, когда вы меняете что-либо на уровне проекта. Это могут быть уже упомянутые ранее Workspace Settings (settings.json), настройки отдельных языков (jsconfig.json), настройки отладки (launch.json), список доступных тасков (tasks.json) и т.д.

Не забудьте прописать эту директорию в .gitignore.

Рабочая директория

Ввиду специфики моей профессиональной деятельности работа идёт не на уровне всего проекта, а только в отдельностоящем уютном фронтендерском уголке. То есть рабочая директория не совпадает с корневой, на уровне которой был сохранён проект. Это вызывает неудобство при работе с терминалом, т.к. если вы попытаетесь запустить, к примеру, сборщик из корня, то ничего хорошего из этого не выйдет, ведь конфиг запуска лежит в рабочей директории. Т.о. каждый раз при запуске проекта нужно переходить к себе через команду cd, что со временем начинает напрягать.

К счастью, у нас есть возможность определить рабочую директорию проекта. Это как раз та настройка, которую нужно задавать не глобально, а на уровне воркспейса, т.к. в разных проектах местоположение рабочей директории может варьироваться. Например, если относительно корня, вы работаете в директории html, то задаётся это следующим образом:

Конечно, как вариант, можно определять проекты сразу на уровне рабочей директории, но я этого делать не советую, т.к. периодически бывает нужно покинуть свой ламповый уголок, и поменять что-то извне, либо запустить поиск сразу по всему проекту. При таком подходе вам придётся открывать отдельное окно с папкой всего проекта, либо отдельно хранить 2 версии проекта — рабочий и общий, что крайне неудобно.

Встроенный терминал

VSCode имеет встроенный терминал, так что вам больше не понадобятся сторонние приложения для работы с терминалом. Ранее я пользовался ConEmu, теперь же полностью от него отказался. Засчёт того, что терминал встроен в редактор, уменьшается переключение контекста, что увеличивает вашу производительность. Это касается не только терминала, но и любого внешнего инструмента, который мы можем интегрировать прямо в редактор. Дебаггер — также отличный пример.

Терминал доступен из нижней панели. Интересный способ открытия этой панели — это “вытаскивание” её из нижнего бара. Просто попробуйте потащить бар вверх �� Но вообще обычно я использую комбинацию Ctrl + `.

Далее нужно настроить какой терминал вы хотите там видеть. Я использую Git Bash. Для этого указываем его местоположение:

Также по настройкам я отключил у себя звуковое сопровождение:

Имеется возможность добавлять любое количество терминалов. На практике обычно я использую 2 терминала — в одном запущен сборщик, а через второй набиваются нужные команды. При этом удобно разделить терминал на 2 части. Хотя в принципе можно обходиться одним рабочим терминалом, если пользоваться механизмом тасков (об этом далее).

Ctrl + \ — Добавление нового терминала в той же вкладке.

Система контроля версий

Встроенные возможности

VSCode предоставляет интерфейс для работы с системой контроля версий. Этот функционал представлен на вкладке Source Control панели управления и частично в статус баре. На вкладке Source Control выводится список изменённых файлов и имеется поле ввода заголовка коммита. В статус баре указывается текущая ветка и количество несинхронизированных коммитов.

До перехода на VSCode я всегда работал с Git через терминал, но теперь перешёл к управлению через интерфейс, т.к. при таком подходе удаётся тратить на это меньше времени, да и если редактор предоставляет такие возможности, то почему бы ими не пользоваться. Я пользуюсь самыми базовыми командами — рассмотрим их реализации в рамках интерфейса по порядку.

git status. Для отслеживания статуса достаточно посмотреть на представление файлов на вкладке Source Control. Все файлы, в которых были произведены изменения, разбиты по группам Changes, Staged Changes и Merged Changes.
git add. Кнопка “Stage Changes” рядом с именем файла (иконка “+”) добавляет указанный файл. Также можно добавить все файлы разом, если навестись на заголовок “Changes” — появится кнопка “Stage All Changes”.
git checkout. Убирается файл аналогично, через кнопку “Discard Changes” (иконка со стрелкой). Функция “Discard All Changes” также присутствует.
git commit. Коммит производится также на вкладке Source Control. Нужно прописать его заголовок в верхнем поле и нажать Ctrl + Enter (Обычное нажатие Enter переводит строку). Если при осуществлении коммита VSCode не найдёт ни одного индексируемого файла, то предложит добавить все. Этот алерт можно отключить, если хотите выполнять такое действие по умолчанию, но я для надёжности оставил.
git pull / git push. В статус баре выводится количество несинхронизированных коммитов. Нажатие по этой кнопке выполняет синхронизацию, т.е. как раз pull и push. По умолчанию при этом выводится алерт подтверждения, но я его отключил: “git.confirmSync”: false,
git fetch. Чтобы подтянуть свежую информацию по веткам, можно прожать кнопку “Refresh” (иконка с галочкой) вверху панели Source Control. Но я рекомендую подобную синхронизацию автоматизировать. Для этого включаем функцию autofetch, которая будет периодически делать fetch за вас: “git.autofetch”: true,
git checkout. Манипуляция ветками выполняется через кнопку в статус баре. Имя текущей ветки на ней уже написано, после нажатия появится список всех доступных веток. Здесь можно выбрать ветку для перехода или создать новую (checkout -b).

Собственно, это все команды, которые я ранее вводил вручную. Как можно видеть для всех них есть более удобные альтернативы, сводящие работу с Гитом к паре кликов. Расширенный набор команд доступен по кнопке “More Actions…” (иконка “…”) наверху вкладки Source Control, ну и для уникальных сложных случаев всегда доступен терминал.

Кстати, если интересно, какие команды VSCode исполняет под капотом, то их можно увидеть на панели Output, выбрав в качестве источника Git.

Что касается мержа, файлы с конфликтующими изменениями отображаются в группе “Merged Changes”. По этим файлам можно пройтись и решить конфликты через встроенный в код линзы (Code Lens). Они предоставлены в виде кнопок, которые позволяют принять отдельные изменения, либо объединить все. При выборе изменённых файлов в панели Source Control открывается diff, показывающий файл из последнего коммита и текущий файл слева и справа соответственно.

Также отмечу, что VSCode из коробки предоставляет индикаторы на полях, символизирующие изменения по сравнению с последним коммитом (зелёный — новый, синий — изменённый, красный — удалённый). В Sublime Text этот функционал приходилось добавлять через специальный плагин.

После всего сказанного единственное, чего здесь не хватает — это интерфейса для просмотра истории коммитов и поиска авторов отдельных фрагментов. Этот функционал добавляется расширением, о котором и пойдёт речь далее.

GitLens — Git supercharged

GitLens — это многофункциональное расширение, предоставляющее возможности по отслеживанию истории изменений. Оно настолько крупное, что идёт со своим интерфейсом настроек, который можно вызвать через палитру команд. Так что если будете настраивать, то пользуйтесь этим интерфейсом — оттуда убран ряд заумных внутренних команд, которые при необходимости можно найти в основных настройках редактора. Расширение разбито на отдельные группы функционала — пройдёмся по ним:

GitLens Explorer — проводник по коммитам репозитория. Предоставляет возможность просмотра коммитов, как в текущей ветке, так и в остальных. Через ПКМ можно открыть репозиторий в окне браузера. Данная панель доступна с вкладки GitLens на панели управления, но через настройки её можно перенести в основное меню Source Control.
GitLens File History Explorer — история коммитов открытого файла. Также можно перенести в Source Control.
Code Lens — встраиваемая в код через линзы информация по автору и дате последнего изменения для всего документа и/или по отдельным контейнерам. Нахожу её бесполезной и загромождающей соурскод, так что отключил.
Current Line Blame — при фокусе на отдельной строке показывает линзу с информацией по дате, автору и имени коммита, в котором она была в последний раз изменена. Также отключил, т.к. это отвлекает и в целом бесполезно, т.к. при необходимости можно вывести Blame по всему файлу (об этом дальше).
Gutter Blame — отображает слева на полях файла информацию для каждой строки по автору, дате и коммиту, в котором эта строка в последний раз менялась. При выборе строки подсвечиваются также все изменения из того же коммита. Также поддерживается Heatmap — цветные индикаторы, которые тем ярче, чем новее строка. Это крайне наглядный интерфейс, который незаменим, если вас интересуют только последние изменения. Если же нужно найти информацию, когда в принципе был добавлен этот участок кода, то он уже не подойдёт — нужно копаться в File History. Эта функция вызывается по запросу (on-demand) через кнопку сверху справа, и в этом её преимущество над всевозможными дотошными линзами.
Hovers — отображает всплывающее окно с информацией по коммиту с различными кнопками управления. Может активироваться как наведением на строку в режиме Gutter Blame, так и при наведении на линзу в режиме Current Line Blame. Также считаю избыточным.
Status Bar Blame — добавляет информацию по последнему изменению строки в статус бар. При нажатии по умолчанию вызывает командную строку со списком команд.
Modes — GitLens имеет возможность настройки режимов, доступных для быстрого переключения через нижнюю панель. По умолчанию доступны режимы Zen и Review — один для разработки без визуальных отвлекающих факторов, а второй для полноценного обзора. Можно в одном из них отключить линзы, блейм для текущей строки, проводники, ховеры и статус бар, а для второго всё включить. В принципе, рабочий концепт, если вам нравится функционал линз, но они не нужны вам при разработки. Но для себя я понял, что мне хватает включения режима аннотаций (Gutter Blame) при необходимости и прогулок по проводникам с историей в более сложных случаях, так что эта тема с режимами будет избыточна.
Command Line — GitLens предоставляет широкий список команд для фанатов командной строки, но лично я ими не пользуюсь.
Comparison Tools — GitLens позволяет гулять по разным версиям файла в режиме сравнения двух версий файлов. Режим активируется из интерфейса через кнопку “Compare File with Previous Revision” в верхнем правом углу. После активации можно углубляться вглубь истории, пока у вас не закончатся коммиты ��

Я описал основные функции расширения, а что уже из этого использовать, а что нет — дело ваше. Мою сборку для работы с историей коммитов можно видеть на скриншоте наверху раздела — там активирован режим Gutter Blame и открыта вкладка Source Control, на которой можно видеть GitLens Explorer и Gitlens File History Explorer. Также в статус баре можно видеть индикатор Status Bar Blame и сверху справа рядом с горящей кнопкой, активирующей Gutter Blame, кнопку, запускающую Comparison Tools. Остальные перечисленные функции отключены.

В итоге все мои настройки этого расширения сводятся к приведению редактора к минималистичному виду — отключения всех визуальных фич и перемещение всех проводников в меню Source Control. Для себя я нахожу все эти линзы и ховеры бесполезными и вместо этого включаю аннотации всего файла при необходимости. Если вам нравится этот функционал, то предложу настроить modes, чтобы они выводились в review-режиме, но не мешались при разработке. Перемещение же всех проводников в дефолтную вкладку позволяет держать всю работу с Гитом на одной панели, что полностью убирает дополнительную вкладку из интерфейса и на практике повышает частоту пользования все данным функционалом и упрощает работу в целом.

�� Поздравляю! Вы дочитали первую часть статьи (или проскролили до футера). Здесь мы рассмотрели базовые возможности VSCode и различные подходы в его применении, а также прописали ряд полезных настроек. Но самое интересное ещё впереди: дебаг и линтинг на уровне редактора, упрощение работы через механизмы тасков и автосаджест Intellisense, список полезных расширений и многое другое. Чтобы продолжить чтение, просто перейдите по этой ссылке.

Если вам есть, что сказать, то оставляйте комментарии. Любой фидбек — это приятно ��

Should I commit the .vscode folder to source control?

Is the .vscode folder meant to be committed to source control?

In a fresh project, the folder is empty, except the settings.json file. What kind of things would go into this folder? Is it machine-specific, developer-specific like the .vs folder and thus not be committed? Or should all developers share this folder and thus it should be committed?

The comment at the top of the file .vscode/settings.json states:

This seems to imply that the folder should contain project-specific settings and thus be included in source. Also, this post on UserVoice seems to imply some typings would go in there, also suggesting that it should be committed.

9 Answers 9

Check in the .vscode folder if you want to share settings, task configuration and debug configuration with the team. I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team. We in the VS Code team share debug and task specific settings as well because we want our team to have the same set of debug targets and task targets for VS Code.

Btw you do not need to have a .vscode folder in your project for settings. You can also configure settings on a user level.

Commit some files in .vscode folder

Recommendation is to generally exclude .vscode folder, but leave select JSON files that allow other developers to recreate shared settings.

Examples of settings to include:

Language specific test configurations to run the test suite(s) ( settings.json )
Extension settings for linters and code formatting tools to enforce the language rules used in this repo ( settings.json )
Run and debug configurations ( launch.json )
Shared tasks — if managed with VS Code ( tasks.json )

Note that some settings can be stored in the user settings or workspace file, or transferred to it from the .vscode folder. See below.

Sample .gitignore code

Here are the settings, as suggested at https://gitignore.io. You can search for "VisualStudioCode" there to get the latest recommended .gitignore file. I use this website as a starting point for .gitignore for most of my new repos:

In the above .gitignore file, the .vscode/* line (note: some debate on whether the * should be included — see comments; .vscode/**/* may be better to ignore nested folders as well) says to exclude everything in the .vscode folder, but then the !.vscode/a_specific_file lines tell git to "not" ignore some specific files in that folder ( settings.json , launch.json , etc.). The end result is that everything is excluded in the .vscode folder except for the files specifically named in one of those other lines.

Other Factors

Including the .vscode folder in your repo doesn’t actually hurt anyone that uses a different IDE (or text/code editor).

However, it may cause issues for other people using VS Code, or some of the settings may not load properly, if these files include generic settings that require something specific to your environment — like the absolute path the repo is installed in. The key is to avoid saving settings that are custom to your local environment, only sharing those that can (or, in the case of this repo, should) be used by everyone.

For example, if IDE setting files have absolute paths to the repo or any files/libraries, etc., then that is bad, don’t share. But if all the references are relative, then they should work for anyone using the repo (although, be careful about path specification differences between Windows/Unix..).

About User, Workspace, and Folder settings

Note: the settings files in the .vscode folder are generally updated when you make changes to the folder version of the settings — but this appears to depend on how individual extensions are coded, because I’ve run across multiple exceptions to this rule.

If you make changes to the user settings, they are usually stored elsewhere (location depends on OS settings, usually in a home directory).
If you make changes to the workspace settings, they are usually stored in the *.code-workspace file that you are currently using. If you don’t have a workspace (you directly opened a folder instead), then they will likely go to the .vscode folder, but, overall, this may depend on the extension that owns the setting anyway.

So, you should generally put custom settings for your personal PC into the user settings, and put generic settings into the workspace or folder settings.