VS Code Remote WSL: Налаштування, що відчувається як рідне

Що насправді означає «відчувається як рідне»

«Рідне» — це не настрій. Це вимірюваний набір властивостей:

• Швидкий ввід/вивід файлів, коли ваш редактор і інструменти не караються за читання великої кількості маленьких файлів.
• Передбачувані шляхи, щоб інструменти не плуталися через монтування дисків у Windows або дивності UNC.
• Когерентна поведінка Git (кінці рядків, біти режимів файлів, чутливість до регістру) між інструментами Windows і Linux.
• Стабільна мережа, де localhost — це localhost, а порти поводяться однаково щоранку.
• Розширення виконуються там, де треба — Linux-розширення в Linux, UI-розширення в Windows.
• Ергономіка дебагу: коли щось повільно працює або ламається, ви можете довести причину за кілька хвилин.

Якщо ви досягли цього, Remote WSL перестає бути «компромісом Windows» і стає надійною Linux-робочою станцією з приєднаним
Windows GPU та екосистемою додатків. Ви редагуєте у VS Code на Windows, але ваші language servers, компілятори, оболонки та кеші збірки живуть у WSL. Оце й суть.

Кілька фактів, які пояснюють, чому WSL працює (і де підводить)

Декілька контекстних пунктів, які справді корисні, коли ви вирішуєте, куди покласти код, чому слідкувач файлів ламається
або чому «проста» оптимізація стає кратером:

1. WSL 1 (2016) переводив системні виклики Linux. Це було розумно, але мало крайні випадки сумісності. WSL 2 перейшов на справжнє ядро Linux.
2. WSL 2 запускає Linux у легкій ВМ. Ось чому працюють функції ядра і чому тепер у вас є «поведінка, схожа на ВМ», щодо пам’яті.
3. Ранній мережевий стек WSL 2 використовував NAT з плаваючою IP ВМ. Сучасні збірки покращили інтеграцію, але вам досі потрібно знати, яка сторона володіє портом.
4. Файлова система Windows (/mnt/c) зручна, але не швидка. Крос-ОС ввід/вивід файлів має накладні витрати — особливо багато дрібних операцій над файлами.
5. Ext4 всередині WSL — це швидкий шлях. Linux-файлова система всередині ВМ — там, де збірки та менеджери пакетів поводяться як дорослі.
6. VS Code «Remote» — це не просто SSH-хитрість. Він запускає VS Code Server у цільовому середовищі (тут — у WSL), який розміщує розширення й інструменти мови.
7. Обмеження inotify реальні. Великі монорепозиторії можуть перевищувати ліміти слідкувачів і виглядати як «VS Code зламаний», коли це просто налаштування ядра.
8. Чутливість до регістру за замовчуванням різна. Windows історично нечутливий до регістру, Linux — чутливий. Git і інструменти можуть вестися дивно, якщо змішувати припущення.
9. WSL інтегрується з процесами Windows. Ви можете запускати code з WSL і викликати виконувані файли Windows з Linux. Це і фіча, і потенційна пастка.

Одна єдина думка: якщо вам важливі продуктивність і здоровий глузд, тримайте репозиторій у Linux-файловій системі WSL,
а не під /mnt/c. Ви все ще можете відкривати його з Windows через Remote WSL. Оце й хитрість.

Як Remote WSL насправді працює (щоб ви могли діагностувати розумно)

Ментальна модель

У цьому налаштуванні VS Code має дві половини:

• VS Code UI (Windows): вікно редактора, меню, комбінації клавіш, рендеринг.
• VS Code Server (Linux у WSL): language servers, термінали, операції Git, дебагери та більшість розширень.

Коли ви «Відкриваєте папку у WSL», VS Code встановлює (або використовує вже встановлений) серверний компонент у вашому дистрибутиві WSL і потім тунелює
операції редактора через локальний транспорт. Якщо розширення правильно класифіковані, вони запускаються на боці WSL, де знаходиться код.

Звідки береться продуктивність

Більшість скарг «VS Code повільний» у WSL-робочому процесі насправді належать до одного з таких випадків:

• Невірна файлосистема: репозиторій на Windows-диску, інструменти запускаються в Linux, і ви платите штраф за крос-ОС при кожному виклику stat.
• Слідкувачі: занадто багато файлів, низькі inotify-ліміти або інструмент, що переходить на опитування.
• Розширення: розширення тільки для Windows намагається взаємодіяти з Linux-шляхами, або розширення сканує весь ваш домашній каталог.
• Обмеження ресурсів: пам’ять WSL роздувається, swap thrashing або замало процесорів.
• Несумісність мережі: сервіс прив’язаний до 127.0.0.1 у невірному неймспейсі, припущення щодо переспрямування портів або дивні правила фаєрвола.

Якщо ви можете визначити, до якої категорії відноситься проблема, її можна виправити швидко. Якщо не можете — будете пробувати випадкові поради «прискорити VS Code»,
поки не зламаєте оболонку й не відчуєте себе зрадженим.

Цитата, яку варто тримати на стікері, перефразована, бо точні слова тьмяніють у пам’яті: сподівання — не стратегія —
«Hope is not a strategy», часто приписують культурі надійності/операцій. Суть: спочатку вимірюйте, потім змінюйте.

Ідеальне налаштування: робіть так, уникайте цього

1) Розміщуйте код у Linux-файловій системі

За замовчуванням: клоніть у домашній каталог WSL (або інше місце на ext4) і відкривайте через VS Code через Remote WSL.
Це уникає класичного повільного шляху: інструменти Linux виконують велику кількість метаданихних операцій на директоріях, змонтованих з Windows.

Рекомендувана схема:
/home/<you>/src/<project>

Уникайте:
/mnt/c/Users/<you>/src/<project>
якщо репозиторій не крихітний і ви не чіпаєте його лише зрідка.

2) Встановлюйте інструменти у WSL, а не у Windows (для WSL-проєктів)

Node, Python, Go, Rust, Java toolchains: встановлюйте їх у WSL, якщо проєкт живе в WSL. Це зберігає шляхи, права доступу
і поведінку рантайму узгодженими. Використовуйте Windows-інструменти, коли проєкт є Windows-нативним (наприклад, .NET desktop apps).

3) Дотримуйтеся дисципліни у Git

Git — це місце, куди крос-платформена розробка йде в тиху загибель. Вирішіть:

• Де виконуватиметься Git? (Відповідь: у WSL, для WSL-репозиторіїв.)
• Яка політика кінців рядків? (Відповідь: ідеально LF у репозиторіях; забезпечити через .gitattributes.)
• Чи потрібні біти режиму файлу? (Ймовірно так для скриптів; впевніться, що ви не втрачаєте exec-біти.)

4) Будьте явно щодо Docker

Ви можете запускати Docker Engine всередині WSL або використовувати інтеграцію Docker Desktop. Обидві моделі можуть працювати. Режим відмови — змішувати їх
без усвідомлення і потім налагоджувати «чому мій кеш образів зник?» о 2-й ночі.

Виберіть одну модель і дотримуйтеся її на машині.

5) Плануйте слідкувачі файлів і монорепозиторії

Великі репозиторії потребують підвищених inotify-лімітів і селективного слідкування. Інакше ваш редактор, тест-раннер або бандлер перейдуть у
режим опитування і спалюватимуть CPU, ніби їм платять за кожен цикл.

Жарт №1: Слідкувачі файлів як офісні плітки — добре в малих дозах, катастрофа, коли всі підписуються на всіх.

Практичні завдання: команди, виводи та рішення (12+)

Це базові перевірки, які я виконую, коли Remote WSL не відчувається рідним. Кожне завдання містить команду, реалістичний приклад виводу,
що це означає, і рішення, яке ви приймаєте на основі нього.

Завдання 1: Підтвердіть, що ви у WSL 2 (не WSL 1)

cr0x@server:~$ wsl.exe -l -v
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2
  Debian                 Stopped         2

Що це означає: Ваш дистрибутив використовує WSL 2. Добре — функції ядра і сумісність кращі.
Рішення: Якщо ви бачите VERSION 1, конвертуйте його, якщо у вас немає специфічної потреби лише у WSL1.

Завдання 2: Перевірте, де знаходиться репозиторій (швидкий шлях vs повільний шлях)

cr0x@server:~$ pwd
/home/cr0x/src/payments-api

Що це означає: Ви на Linux-файловій системі. Це точка оптимальної продуктивності.
Рішення: Якщо це виводить щось під /mnt/c, перемістіть репозиторій у /home і знову відкрийте у WSL.

Завдання 3: Перевірте тип монтування і опції (ви на /mnt/c?)

cr0x@server:~$ mount | grep -E ' /mnt/c | / '
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)
none on / type overlay (rw,relatime,lowerdir=/mnt/wslg/distro,upperdir=/mnt/wsl/upper,workdir=/mnt/wsl/work)

Що це означає: Диски Windows з’являються як drvfs. Вони підходять для зрідка редагування, але не для важких збірок.
Рішення: Якщо ваш репозиторій на drvfs і збірки повільні — перемістіть його.

Завдання 4: Підтвердьте, що VS Code Server встановлено і де

cr0x@server:~$ ls -la ~/.vscode-server/bin | head
total 12
drwxr-xr-x 3 cr0x cr0x 4096 Jan 10 09:14 .
drwxr-xr-x 9 cr0x cr0x 4096 Jan 10 09:14 ..
drwxr-xr-x 6 cr0x cr0x 4096 Jan 10 09:14 1a2b3c4d5e6f7g8h9i0j

Що це означає: Сервер існує у вашому домашньому каталозі WSL.
Рішення: Якщо ця директорія відсутня і Remote WSL не може підключитися, інсталяція не вдається — перевірте логи (Завдання 5).

Завдання 5: Прочитайте логи Remote WSL з боку сервера

cr0x@server:~$ ls -la ~/.vscode-server/.cli/logs | tail -n 3
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:15 20260110T091500
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:20 20260110T092000
drwxr-xr-x 2 cr0x cr0x 4096 Jan 10 09:25 20260110T092500

cr0x@server:~$ tail -n 30 ~/.vscode-server/.cli/logs/20260110T092500/remoteagent.log
[2026-01-10 09:25:14.101] info  Extension host started
[2026-01-10 09:25:14.223] info  Listening on /run/user/1000/vscode-ipc-2f9a.sock
[2026-01-10 09:25:16.012] warn  File watcher failed to start (ENOSPC)

Що це означає: Віддалений агент запущений, але слідкувач файлів не зміг стартувати через ENOSPC (ліміт inotify).
Рішення: Підвищіть inotify-ліміти (Завдання 10) і перезапустіть VS Code.

Завдання 6: Переконайтеся, що Git — це Linux Git (а не Windows Git) для WSL-репозиторіїв

cr0x@server:~$ which git
/usr/bin/git

cr0x@server:~$ git --version
git version 2.34.1

Що це означає: Ви використовуєте Linux Git.
Рішення: Якщо which git показує шлях Windows через інтероп, виправте порядок PATH або вимкніть інтероп для цього робочого процесу.

Завдання 7: Виявити проблеми з кінцями рядків до того, як це перетвориться на тижневий спор

cr0x@server:~$ git config --show-origin --get core.autocrlf
file:/home/cr0x/.gitconfig  input

Що це означає: input конвертує CRLF у LF при коміті, але залишає робоче дерево як є (зазвичай LF у Linux).
Рішення: Для WSL-репозиторіїв віддавайте перевагу input або false і забезпечуйте політику через .gitattributes.

Завдання 8: Перевірте, чи випадково не працюєте у Windows-шляху через UNC

cr0x@server:~$ ls -la /mnt/wsl | head -n 5
total 0
drwxr-xr-x  4 root root  80 Jan 10 08:01 .
drwxr-xr-x 15 root root 340 Jan 10 08:01 ..
drwxr-xr-x  2 root root  40 Jan 10 08:01 instances
drwxr-xr-x  2 root root  40 Jan 10 08:01 services

Що це означає: Ви дивитесь на інфраструктурні монтування WSL. Сама по собі це не проблема.
Рішення: Пастка — зберігати репозиторії в Windows-локаціях і відкривати їх через шлях, що виглядає «ніби Linux», але таким не є.
Тримайте репозиторії в /home, і вас це не турбуватиме.

Завдання 9: Перевірте використання диска у WSL (чи не заповнений віртуальний диск?)

cr0x@server:~$ df -hT / /home
Filesystem     Type   Size  Used Avail Use% Mounted on
overlay        overlay 251G  210G   29G  88% /
overlay        overlay 251G  210G   29G  88% /

Що це означає: У вас мало вільного місця. Менеджери пакетів та language servers не домовляються з повними дисками.
Рішення: Почистіть кеші, видаліть непотрібні Docker-образи або збільште віртуальний диск WSL, перш ніж почнуться випадкові відмови.

Завдання 10: Виправити помилки «ENOSPC» для слідкувачів (збільшити inotify-ліміти)

cr0x@server:~$ cat /proc/sys/fs/inotify/max_user_watches
8192

cr0x@server:~$ sudo sh -c 'printf "fs.inotify.max_user_watches=524288\nfs.inotify.max_user_instances=1024\n" > /etc/sysctl.d/99-inotify.conf'

cr0x@server:~$ sudo sysctl -p /etc/sysctl.d/99-inotify.conf
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 1024

Що це означає: Ви підвищили місткість слідкувачів.
Рішення: Якщо у вас великий репозиторій (монорепо, node_modules, виводи bazel), це часто обов’язково. Перезапустіть VS Code, щоб повторно прикріпити слідкувачі.

Завдання 11: Подивіться, чи інструмент опитує файлову систему (ознака перегріву CPU)

cr0x@server:~$ ps aux --sort=-%cpu | head
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x     13240 85.1  3.2 2869136 528400 ?      Sl   09:12   6:18 node /home/cr0x/src/payments-api/node_modules/.bin/webpack --watch
cr0x     11422 22.4  1.1 1462032 182220 ?      Sl   09:14   1:41 /home/cr0x/.vscode-server/node ... extensionHost

Що це означає: Щось завантажує CPU. Може бути законна компіляція, а може — режим опитування.
Рішення: Якщо CPU завантажений у стані простою, перевірте помилки слідкувачів (Завдання 5/10) і налаштування інструменту (виключати директорії збірки, використовувати нативні слідкувачі).

Завдання 12: Перевірте тиск пам’яті у WSL і swap thrash

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi        13Gi       420Mi       256Mi       1.7Gi       1.1Gi
Swap:          8.0Gi       6.5Gi       1.5Gi

Що це означає: У вас інтенсивне використання swap. Продуктивність почуватиметься як ходіння по мокрому цементу.
Рішення: Зменшіть паралельність збірок, закрийте «некеровані» процеси або налаштуйте ресурси WSL. Якщо це відбувається щоденно — виправляйте причину, а не симптом.

Завдання 13: Виявити великі директорії, що псують індексацію (зазвичай node_modules або виходи збірки)

cr0x@server:~$ du -h -d 1 . | sort -h | tail
120M    ./dist
1.4G    ./node_modules
2.1G    .

Що це означає: Індексація і слідкування будуть дорогими, якщо редактор сприймає ці папки як вихідний код.
Рішення: Додайте виключення у налаштування VS Code і конфіги інструментів; розгляньте варіанти менеджера пакетів, що зменшують churn.

Завдання 14: Підтвердити поведінку прив’язки портів (сервіс доступний?)

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:3000      0.0.0.0:*       users:(("node",pid=14222,fd=20))
LISTEN 0      4096   0.0.0.0:5432        0.0.0.0:*       users:(("postgres",pid=981,fd=5))

Що це означає: Ваш dev-сервер прив’язаний лише до loopback (127.0.0.1). Це нормально, якщо ви звертаєтесь з того ж неймспейсу.
Рішення: Якщо Windows не може до нього дістатися, прив’яжіть до 0.0.0.0 там, де це безпечно для деву, або використайте можливості Remote переспрямування портів.

Завдання 15: Перевірка DNS і з’єднання зсередини WSL

cr0x@server:~$ getent hosts github.com | head -n 1
140.82.114.4    github.com

cr0x@server:~$ ping -c 1 github.com
PING github.com (140.82.114.4) 56(84) bytes of data.
64 bytes from 140.82.114.4: icmp_seq=1 ttl=49 time=18.2 ms

--- github.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Що це означає: DNS і вихідне підключення працюють.
Рішення: Якщо DNS хиткий, зосередьтесь на мережевих налаштуваннях WSL і політиці корпоративного VPN split-tunnel, а не звинувачуйте VS Code.

Завдання 16: Перевірте ситуацію з SSH-агентом (щоб уникати запитів пароля кожні 3 хвилини)

cr0x@server:~$ ssh-add -l
The agent has no identities.

Що це означає: Ключі не завантажені. Вас питатимуть пароль, або операції Git не вдаватимуться.
Рішення: Завантажте ключі в агент у WSL або використовуйте Windows-агент, акуратно з’єднавши його. Безпечний підхід: тримати SSH-ключі й агент у WSL для WSL-репозиторіїв.

Завдання 17: Підтвердьте ліміти дескрипторів файлів (рідко, але реальна проблема у великих інструментах)

cr0x@server:~$ ulimit -n
1024

Що це означає: Низький FD-ліміт може ламати великі слідкувачі, інструменти збірки або тест-ранери.
Рішення: Якщо бачите «too many open files», підвищте його через shell-ліміти і/або системну конфігурацію (обережно, з погодженням в команді).

Швидка методика діагностики

Коли Remote WSL відчувається повільним або зламаним, не блукайте. Виконайте стислий цикл, що швидко визначає клас вузького місця.

По-перше: доведіть, де лежить репозиторій і де працюють інструменти

• У терміналі WSL всередині VS Code: pwd і mount | grep /mnt/c.
• Якщо ваш репозиторій під /mnt/c, вважайте накладні витрати файлової системи як першу гіпотезу.
• Підтвердіть, що ви використовуєте Linux-рутулі: which git, which node, which python.

По-друге: перевірте здоров’я слідкувачів і тиск індексації

• Подивіться логи сервера на ENOSPC або помилки слідкування.
• Перевірте /proc/sys/fs/inotify/max_user_watches.
• Оцініть роздування репозиторію: du -h -d 1 . | sort -h | tail і вирішіть, що виключити.

По-третє: перевірте CPU, пам’ять і swap

• ps aux --sort=-%cpu | head щоб зловити «некеровані» слідкувачі та компілятори.
• free -h щоб помітити swap thrash.
• Якщо пам’ять напружена, зменшіть паралельність, вбити процес-набридник, а потім налаштуйте ресурси WSL як політику — не як ритуал.

По-четверте: перевіряйте мережу лише після вищевказаного

• ss -lntp для перевірки прив’язки портів.
• getent hosts для діагностики DNS.
• Тільки потім чіпайте налаштування фаєрвола/VPN — інакше «ви виправите» не той рівень і зламаєте щось інше.

Жарт №2: Якщо вашим першим кроком дебагу є перевстановлення VS Code, ви не діагностуєте — ви робите екзорцизм.

Поширені помилки: симптом → причина → виправлення

1) «Все повільно, особливо npm install / git status / індексація TypeScript»

Симптом: Команди, що торкаються багато файлів, повзають; вентилятори шумлять; VS Code відчувається важким.

Причина: Репозиторій знаходиться на /mnt/c (drvfs), а інструменти працюють у WSL.

Виправлення: Перемістіть репозиторій у /home/<you>/src, переклоніть за потреби, знову відкрийте через Remote WSL.

2) «VS Code не може стежити за файлами; зміни не запускають перебудову; логи показують ENOSPC»

Симптом: Авто-перезавантаження зупинилося, тести не перезапускаються, хост розширень попереджає про слідкувачі.

Причина: Ліміти inotify занадто малі для розміру репозиторію.

Виправлення: Збільшіть fs.inotify.max_user_watches і max_user_instances (Завдання 10), потім перезапустіть.

3) «Git постійно показує величезні дифи, або файли змінюють кінці рядків»

Симптом: Кожен коміт включає не пов’язані зміни; колеги сперечаються через CRLF.

Причина: Змішані налаштування Git між Windows і WSL; відсутній .gitattributes.

Виправлення: Стандартизувати LF у репозиторії через .gitattributes; використовувати Linux Git у WSL; встановити core.autocrlf=input (або false) для WSL-робочих потоків.

4) «Remote WSL постійно відключається або застрягає на ‘Installing VS Code Server’»

Симптом: Петля перепідключення; інсталяція сервера ніколи не завершується.

Причина: Заповнений диск, проблеми з правами в домашньому каталозі або пошкоджена інсталяція сервера.

Виправлення: Перевірте df -h, перегляньте логи під ~/.vscode-server/.cli/logs, і видаліть проблемну версію сервера, щоб змусити його перевстановитися.

5) «Порти працюють у WSL, але не з браузера Windows»

Симптом: Сервіс доступний через curl localhost у WSL, але Windows не підключається.

Причина: Сервіс прив’язаний до 127.0.0.1 всередині неймспейсу WSL; припущення щодо переспрямування портів невірні.

Виправлення: Прив’яжіть до 0.0.0.0 у dev-режимі, де це безпечно, або використайте Remote переспрямування портів; перевірте з ss -lntp.

6) «Моя збірка використовує Windows-інструменти навіть у WSL»

Симптом: Дивні шляхи; коливання продуктивності; бінарні файли у несподіваних місцях.

Причина: Інтероп Windows у PATH призводить до того, що Windows-екзешники вибираються першими.

Виправлення: Перевірте через which; змініть порядок PATH; будьте явними у скриптах; розгляньте обмеження інтеропу для дев-шелів.

7) «Docker-образи зникають залежно від того, де я виконую команди»

Симптом: docker images відрізняється між терміналами; збірки повторюються постійно.

Причина: Змішування інтеграції Docker Desktop і окремого Docker Engine у WSL.

Виправлення: Виберіть одне: контекст Desktop або нативний engine. Стандартизувати на одному варіанті на машину і документувати рішення команді.

8) «Перейменування лише регістром поводиться некоректно; імпорти падають у CI, але на локалі працюють»

Симптом: Працює на вашій машині, падає в Linux CI або навпаки.

Причина: Невідповідність чутливості до регістру і Git не фіксує очікувану семантику перейменування.

Виправлення: Робіть перейменування обережно (через тимчасову назву, потім фінальну), переконайтеся, що CI відповідає продакшну, і не зберігайте репозиторії на нечутливих монтуваннях, якщо потрібна Linux-семантика.

Три корпоративні міні-історії з передової

Інцидент: неправильне припущення (місце розташування репозиторію «не важливе»)

Команда, що мігрувала з MacBook на Windows, хотіла «переключитися за вихідні». Вони обрали WSL 2, встановили VS Code і оголосили перемогу
після того, як демонстраційний додаток зібрався успішно. Припущення було неявне: «файли — це файли, а сховище — це сховище».

До понеділка після обіду розробники почали повідомляти, що git status виконується вічно, тести непослідовні, і TypeScript
language services часто тайм-аутяться. Швидкі спроби виправити почалися: перевстановити розширення, підняти версії Node, і перемкнути випадкові налаштування.
Результат: різні відмови, та сама фрустрація.

Причина була банальною: репозиторії були склонировані в C:\Users\...\src і відкриті через WSL. Отже кожен інструмент у Linux
громив drvfs десятками тисяч метаданихних операцій. На маленькому репозиторії ви можете ніколи цього не помітити. На корпоративному монорепо
це податок, який ви платите за кожен натиск клавіші.

Виправлення було так само банальне: перемістити клон у /home, знову відкрити в Remote WSL і припинити запуск Windows Git проти WSL робочих дерев.
Протягом дня скарги припинилися. Не через магію. Бо інструменти нарешті працювали на файловій системі, для якої вони призначені.

Оптимізація, що дала зворотний ефект: «Поділимо node_modules на Windows»

Інша група спробувала хитру оптимізацію з кешуванням. На їхніх Windows-лаптопах було багато місця, і вони хотіли уникнути повторних інсталяцій у WSL.
Ідея: тримати node_modules на боці Windows і прив’язувати/створювати симлінк у проєктах WSL. Одна інсталяція, багато проєктів,
менше завантажень. Усім подобаються менші завантаження.

Приблизно два дні це здавалося успіхом. Інсталяції стали швидшими — принаймні перший раз. Потім почалися дивності: нативні модулі відмовлялися збиратися,
бінарні файли мали неправильні ABI-очікування, і «працює на моїй машині» став «працює до перезавантаження». Слідкування за файлами стало гіршим, а не кращим.

Схована проблема в тому, що вони оптимізували не ту вузьку частину. Вузьке місце не було в завантаженні пакетів; воно було в файлових операціях і крос-ОС
семантиці. Екосистема Node виконує багато дрібних файлових операцій і очікує POSIX-поведінки. Перенесення найгарячіших директорій на drvfs привело до
дивних краївих випадків і постійного технічного боргу продуктивності.

Вони відкотили зміни і прийняли чисте правило: залежності живуть з проєктом в ext4, кеші дозволені, але мають бути WSL-нативними, а команда використовує реальний mirror registry
лише якщо мережа — це вузька частина. Їхні збірки стали передбачуваними знову, а передбачуваність — це той «швидкий» результат, який можна планувати.

Нудна, але правильна практика, яка врятувала ситуацію: стандартизація базової конфігурації деву

Платформна команда, що підтримувала кілька продуктових команд, мала іншу проблему: не продуктивність, а непослідовність. Усі дистрибутиви WSL дрейфували.
Різні версії Ubuntu, різні системні пакети, різні Git-настройки. Налагоджувальні тікети перетворювалися на археологію.

Вони зробили негарну роботу: базовий чеклист і одноразовий bootstrap-скрипт. Він перевіряв WSL 2, забезпечував розміщення репозиторіїв у /home,
встановлював inotify-ліміти, фіксував невеликий набір версій toolchain і виводив чіткі повідомлення, коли щось не відповідає.
Ніякого гарного UI. Просто дисципліновані за замовчуванням.

Через тижні оновлення Windows спричинило хвилю звітів про «Remote WSL відключився». Команди, що дотримувались бази, відновлювалися за кілька хвилин,
бо мали відомі добрі контрольні точки: вільний диск, шлях до логів сервера і невеликий набір конфігураційних файлів для порівняння. Команди без бази
втратили по півдня на випадкових форумних виправленнях.

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

Контрольні списки / покроковий план

Контрольний список A: Базова «відчуття рідного» (зробіть один раз на машину)

1. Підтвердіть WSL 2: wsl.exe -l -v показує VERSION 2 для вашого дистрибутиву.
2. Оновіть пакунки у WSL і встановіть основні інструменти (git, build essentials, toolchains мов програмування).
3. Створіть адекватну робочу директорію: ~/src і клоніть туди репозиторії.
4. Відкрийте VS Code через Remote WSL, запустивши code . зсередини репозиторію у WSL.
5. Підвищіть inotify-ліміти (особливо для JS/TS, монорепо): задайте значення sysctl і застосуйте їх.
6. Встановіть політику Git: оберіть LF і забезпечте через .gitattributes; переконайтеся, що WSL Git використовується для WSL-репозиторіїв.
7. Вирішіть модель Docker: інтеграція Desktop чи нативний engine — оберіть одне і задокументуйте його для себе.
8. Виключіть сміттєві директорії у налаштуваннях VS Code: виходи збірки, папки залежностей, кеші інструментів за потреби.
9. Переконайтеся, що SSH працює: ключі та агент доступні у WSL для операцій Git.

Контрольний список B: Підключення нового репозиторію (на проєкт)

1. Клонувати у ~/src у WSL.
2. Відкрити за допомогою code . (з WSL), щоб VS Code правильно прикріпився.
3. Запустити bootstrap-команду проєкту і слідкувати за попередженнями слідкувачів файлів.
4. Перевірити експозицію портів з ss -lntp і вирішити, чи має прив’язуватися до 127.0.0.1 або 0.0.0.0.
5. Перевірити використання диска після інсталяції залежностей (df -h, du) і вирішити, чи потрібні правила очищення.

Контрольний список C: Коли раптом стало повільно (10-хвилинна триаж)

1. Чи репозиторій під /mnt/c? Якщо так, зупиніться і перемістіть його.
2. Чи логи показують ENOSPC? Якщо так, підніміть inotify-ліміти.
3. Чи CPU завантажений у стані простою? Визначте процес і чи опитує він чи виконує справжню роботу.
4. Чи сильно використовується swap? Зменшіть паралельність і вбийте процес-набридник; потім налаштуйте ресурси.
5. Лише потім: перевірте мережу та обмеження VPN.

Часті питання (FAQ)

1) Чи зберігати репозиторії у Windows і просто використовувати інструменти WSL?

Ні для всього, що не тривіальне. Це найпоширеніша причина звітів «WSL повільний». Покладіть репозиторії у Linux-файлову систему WSL і відкривайте їх через Remote WSL.

2) Чи WSL 2 завжди кращий за WSL 1 для VS Code Remote?

Для сучасних стеків розробки — так. Справжнє ядро WSL 2 покращує сумісність і поведінку інструментів. WSL 1 може бути прийнятним для певних I/O-шаблонів, але зараз це виняток.

3) Чому VS Code встановлює щось всередині WSL?

Тому що Remote WSL запускає VS Code Server у Linux-середовищі. Цей сервер розміщує розширення й інструменти мови поруч з вашим кодом і toolchain.

4) Моє розширення працює у Windows, але не у WSL. Це баг?

Іноді це просто те, що розширення працює не на тій стороні. Деякі розширення мають виконуватися там, де файли й інструменти. Віддавайте перевагу розширенням, які коректно підтримують віддалене виконання.

5) Як зробити, щоб слідкувачі файлів не плавили мій CPU?

По-перше, підвищіть inotify-ліміти, якщо бачите ENOSPC. По-друге, виключіть виходи збірки і папки залежностей з перегляду/індексації. По-третє, перевірте, чи якийсь інструмент не опитує систему.

6) Який найкращий підхід для SSH-ключів: Windows-агент чи WSL-агент?

Для WSL-репозиторіїв краще тримати ключі і агент усередині WSL. Це зменшує дивні поведінки на межі. Якщо корпоративна політика вимагає ключі під управлінням Windows — підключайте обережно і тестуйте.

7) Чому Windows не бачить мій WSL-сервіс на localhost?

Зазвичай тому, що сервіс прив’язаний до 127.0.0.1 всередині WSL, або переспрямування портів налаштоване не так, як ви думаєте. Перевірте з ss -lntp і прив’яжіть відповідно.

8) Чи можу я використовувати Docker у WSL без Docker Desktop?

Так, можна запускати Docker Engine у WSL. Головне — послідовність: не змішуйте це з контекстами Docker Desktop, якщо не любите шукати фантомні кеші.

9) Чому Git поводиться по-різному між Windows і WSL?

Різниці включають кінці рядків, біти режиму файлу і припущення щодо чутливості до регістру. Обирайте одне середовище Git для репозиторію (WSL Git для WSL-репозиторіїв) і застосовуйте політику через .gitattributes.

10) Яке одне найкраще покращення «відчуття рідного»?

Перемістіть репозиторій у Linux-файлову систему WSL. Усе інше — це налаштування навколо цього фундаментального рішення.

Висновок: практичні наступні кроки

Якщо ви хочете, щоб Remote WSL відчувався як рідне, припиніть ставитись до нього як до дивацтва і почніть сприймати його як робочу станцію з топологією. Покладіть код туди, де інструменти Linux швидкі.
Запускайте інструменти там, де семантика файлової системи збігається. Встановлюйте ліміти слідкувачів свідомо. І коли щось ламається — спочатку вимірюйте.

Наступні кроки, які ви можете зробити сьогодні:

• Створіть ~/src у WSL і переклоніть один середній репозиторій туди.
• Відкрийте його з code . з WSL і перевірте which git та pwd.
• Профілактично підвищіть inotify-ліміти, якщо у вас великий репозиторій або JS-стек.
• Одного разу пройдіть швидку методику діагностики, коли все «добре», щоб знати, як виглядає нормальний стан.

Виграш — не лише у швидкості. Це передбачуваність. А передбачуваність дозволяє відвантажувати без перетворення вашого ноутбука на другу роботу.