Deno 2.8: як протестувати CI, npm audit і Node-сумісність без повної міграції

Зачіпка

Deno — це runtime для JavaScript і TypeScript, тобто програма, яка запускає JS/TS-код. Його часто порівнюють із Node.js: Deno теж уміє працювати з npm-пакетами, але має іншу модель безпеки, вбудовані інструменти й TypeScript без окремого налаштування.

Deno 2.8 легко прочитати як черговий опис оновлення для фанатів альтернативних середовищ запуску. Але найцікавіша частина релізу не в тому, щоб сьогодні переписати Node-проєкт на Deno.

Практичніший підхід: додати Deno 2.8 як маленьку окрему перевірку в CI, тобто в автоматичний процес, який після змін запускає тести й технічні перевірки. Так можна перевірити lockfile, швидше розібрати npm-вразливості, пояснити залежності через deno why і зрозуміти, де нова Node-сумісність реально допомагає, а де ще рано ризикувати.

Проблема / контекст

Команди часто не хочуть чіпати runtime, бо заміна середовища запуску звучить як дорогий рефакторинг. І це чесний страх. Якщо застосунок працює на Node, викладається на робочий сервер, має набір тестів, старі npm-скрипти, пакети з нативним кодом і купу дрібних припущень, фраза “давайте спробуємо Deno” може звучати як запрошення до хаосу.

Deno 2.8 зменшує поріг не тим, що обіцяє магічну міграцію. Реліз додає інструменти, які можна тестувати окремо:

• deno ci як явний крок повторюваного встановлення залежностей у CI;
• deno audit --fix для частини виправлень npm-вразливостей без переходу на нову major-версію;
• deno why для пояснення, чому пакет взагалі потрапив у дерево залежностей;
• CLI, який став ближчим до npm: deno add express більше не впирається в обов’язковий npm: префікс;
• помітно кращу сумісність із Node, але все ще не обіцянку 100% сумісності.

Тобто розмова має бути не “Node або Deno”, а “який маленький шматок робочого процесу можна перевірити без переписування застосунку”.

Чому це важливо

CI зазвичай ламається не від великої ідеології, а від дрібної неповторюваності. Один lockfile локально, інший стан кешу на сервері CI, службовий скрипт пакета спрацював не там, перевірка безпеки знайшла вразливість, але незрозуміло, яку залежність можна оновити без великого переходу на нову major-версію.

deno ci робить крок встановлення залежностей більш прямим: він очікує lockfile, чистить попередній node_modules і запускає встановлення без зміни версій. Для автоматичної перевірки це зручний сигнал: якщо lockfile і конфіг роз’їхались, job має впасти явно.

deno audit --fix закриває іншу частину болю. Він не намагається героїчно переписати все дерево залежностей. Документація Deno прямо описує обмеження: автоматично оновлюються вразливі direct dependencies до виправлених версій у межах дозволеного semver-діапазону; major upgrades, незвичні стилі запису версій і transitive cases без чистого direct path пропускаються.

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

Як це зробити

1. Не починайте з runtime на робочому сервері

Перша пробна перевірка має бути нудною. Візьміть репозиторій, де є package.json, lockfile і CI, але не міняйте команду запуску на робочому сервері.

Почніть з окремої гілки:

deno upgrade
deno --version
deno install

Якщо проєкт залежить від локального node_modules, одразу перевірте режим. Для частини Deno-проєктів глобального кешу достатньо, але фреймворки, збірники та пакети з нативним кодом часто очікують локальний node_modules.

Мінімальний deno.json для такого випадку:

{
  "nodeModulesDir": "manual"
}

Це не “міграція на Deno”. Це спосіб чесно сказати Deno, що ваш Node-проєкт живе в ручному процесі встановлення залежностей.

2. Додайте deno ci як окремий сигнал

У GitHub Actions така окрема перевірка може виглядати так:

jobs:
  deno-pilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x
      - run: deno ci
      - run: deno audit

Поки що не замінюйте основний npm ci. Поставте Deno-перевірку поруч, щоб побачити, чи lockfile і модель встановлення проходять без побічних ефектів.

Критерій успіху простий: deno ci стабільно проходить на чистому сервері CI, а команда розуміє, що саме він перевіряє.

3. Використайте deno audit --fix як помічник для PR, а не як автопілот

deno audit --fix краще запускати в окремій гілці:

deno audit
deno audit --fix
git diff

Якщо інструмент оновив direct dependency у межах дозволеного semver-діапазону, це хороший кандидат на маленький PR. Якщо він повідомив, що major upgrade не може бути виправлений автоматично, не треба ламати constraint у паніці. Це окрема задача: changelog, тести й нотатки з міграції.

Для CI здоровіше розділити:

- run: deno ci
- run: deno audit --level=high

--fix у CI без перегляду людиною може створити дивні зміни або приховати важливе рішення. Нехай CI перевіряє, а fix-команда готує diff для людини.

4. Пояснюйте залежності через deno why

Коли audit показує package, команда часто витрачає час на питання “хто це притягнув?”. У Deno 2.8 є deno why <package>, схожий за роллю на npm explain, pnpm why або yarn why.

Приклад процесу:

deno why qs
deno why body-parser

Це особливо корисно під час перегляду PR. Замість абстрактного “вразливий transitive package” можна записати: пакет приходить через конкретну direct dependency, а значить рішення таке-то: оновити цю direct dependency, чекати upstream або планувати major upgrade.

5. Не перебільшуйте сумісність із Node

Deno 2.8 сильно просунувся в сумісності з Node: в описі релізу Deno показує стрибок успішних перевірок у тестовому наборі Node до 76.4%. Це суттєво. Але 76.4% не дорівнює “будь-який Node-проєкт можна завтра перевести”.

Що варто пробувати:

• процес встановлення й audit-перевірки;
• окремі scripts;
• CLI tools;
• невеликі services без складних native dependencies;
• test jobs, де легко порівняти результат.

Що краще не чіпати першим:

• runtime на робочому сервері для критичного API;
• jobs із native addons без окремої перевірки;
• складні фреймворки, які дуже конкретно очікують Node/npm behavior;
• deployment scripts, де rollback повільний.

Пілот має дати знання, а не довести тезу.

Антипатерни

• Замінити npm ci на deno ci в основному процесі робочого сервера без паралельної пробної перевірки.
• Запускати deno audit --fix у CI так, ніби це безпечний бот для автоматичних виправлень.
• Вважати 76.4% успішних перевірок у тестовому наборі Node гарантією сумісності вашого набору інструментів.
• Ігнорувати nodeModulesDir, якщо інструменти очікують локальний node_modules.
• Змішати install-перевірку, виправлення безпеки й перехід на інший runtime в один MR.
• Оновити major dependency тільки тому, що audit показав вразливість.
• Не мати rollback до попереднього процесу встановлення й audit-перевірки.

Висновок / план дій

Deno 2.8 вартий уваги не як причина терміново тікати з Node, а як практичний набір інструментів для сильнішого CI і зрозумілішого процесу роботи із залежностями.

Мінімальний здоровий rollout:

1. вибрати один Node repo для пробної перевірки;
2. додати Deno 2.8 в окрему CI job;
3. запустити deno ci без заміни npm ci;
4. додати deno audit як сигнал безпеки;
5. використовувати deno audit --fix тільки для PR, які переглядає людина;
6. пояснювати проблемні packages через deno why;
7. перевірити nodeModulesDir і межі сумісності;
8. після кількох зелених прогонів вирішити, що лишати.

Офіційні джерела:

• https://deno.com/blog/v2.8
• https://docs.deno.com/runtime/reference/cli/audit/
• https://docs.deno.com/runtime/reference/continuous_integration/
• https://docs.deno.com/runtime/fundamentals/node/