Як налаштувати повноцінну розробку в Visual Studio Code в браузері

Головне

• Історія VS Code пояснює його «віддалені» суперсили: він починався (~2011) як веб-редактор Monaco (який і сьогодні можна вбудувати у власний застосунок), переїхав на Electron (API Node.js + API браузера, UI на HTML/CSS), а коли додали плагіни, їх свідомо винесли в окремий процес, що спілкується з ядром, — заради швидкого старту і стабільності.
• Щоб підтримати багато мов, Microsoft додала language servers: ще один окремий процес на кожну мову, що говорить JSON-RPC за Language Server Protocol. Отже, редактор і так уже складався з процесів ядра + extension host + language server.
• Windows Subsystem for Linux змусив зробити наступний крок: UI працює на Windows, а код і процеси — у Linux. Оскільки розширення вже були окремим процесом, рішенням став агент (зі своїми розширеннями та language server-ами), з яким спілкується ядро, — а SSH-агент майже не відрізняється від локального. Найважчою була чисто браузерна підтримка (ядру довелося позбутися всіх залежностей від API Node.js) — вона зʼявилася лише у 2020-му.
• SSH-демо: з розширенням Remote-SSH підключення до хоста змушує VS Code непомітно встановити власний vscode-server на віддаленій машині — він доводить це, показуючи відсутність процесів до підключення і запущений VS Code server разом із директорією ~/.vscode-server після.
• Далі все працює «ніби локально»: термінал — віддалений, порти прокидаються автоматично (його Node.js hello-world на віддаленому порту 3000 відкривається локально на 127.0.0.1:3000), а розширення поділені на «локальні» та «віддалені» — він ставить Prettier на сервер, і форматування при збереженні та дебаг із брейкпоінтами просто працюють.
• Суто браузерний сетап: заходиш на vscode.dev, логінишся через GitHub, потім на сервері завантажуєш standalone-бінарник VS Code CLI і запускаєш code tunnel; одна авторизація через код на github.com/login/device, назва машини — і маєш tunnel-URL на vscode.dev, доступний із будь-якої машини.
• Навіщо потрібен логін через GitHub: до свого сервера ти не підключаєшся напряму — і браузер, і сервер підключаються назовні до проксі (він вважає, через WebSockets), яке зшиває тунель. Тому це працює, навіть коли обидва кінці сидять за NAT і фаєрволами; сам застосунок, що дебажиться, отримує спеціальний devtunnels-URL замість localhost.
• Його підсумок простору опцій (що збігається з діаграмою в документації Microsoft): SSH-remoting, WSL, GitHub Codespaces (працює так само, як тунельний сетап, на його думку), браузерні тунелі та dev containers — останні він називає особливо крутими: застосунок і всі розширення працюють у контейнері, даючи відтворюване середовище без жодного кліку.