Які tsconfig файли створювати?
#typescript

Ще один рецепт з налаштування TypeScript. З допомогою --project можна визначити який файл з налаштуваннями використовувати. Приклад із одного з моїх проектів.
"scripts": {
  "build": "tsc --project tsconfig.build.json",
  "test": "jest --config jest.config.ts",
  "typecheck": "tsc --project tsconfig.json",
  "watch": "tsc --project tsconfig.dev.json --watch"
 },

У цьому проекті використовується 4 файли:
👉 tsconfig.json успадковується від @tsconfig. Від нього успадковуються всі інші. Використовується для перевірки типів у команді typecheck.
👉 tsconfig.build.json використовується під час збирання Docker image. Тільки він має "noEmit": false
👉 tsconfig.dev.json відключає правила, які зайві в процесі розробки або troubleshooting. Наприклад: "noUnusedLocals": false
👉 tsconfig.test.json використовується для тестів. Саме його я вказую у jest.config.ts

Кількість файлів буде залежить від вашого проекту та й використовуваних процесів. Просто пам'ятайте налаштування можна міняти в залежності від контексту запуску TypeScript.

Правильний перехід на typescript v5
#typescript

На відміну від решти JavaScript екосистеми, TypeScript не слідує SemVer. Тобто немає різниці в переході між 4.8➡️4.9 та 4.9➡️5.0. В обох випадках можливі breaking changes.

Однак багато пакетів не використовують цю інформацію та в залежностях вказують, що очікують TypeScript@4.x. Приклад помилки під час install:
npm ERR! Could not resolve dependency:
npm ERR! peer typescript@"^3.7.5 || ^4.0.0" from eslint-plugin-deprecation@1.3.3
npm ERR! node_modules/eslint-plugin-deprecation
npm ERR!  dev eslint-plugin-deprecation@"^1.3.3" from the root project
Помилки під час встановлення це не страшно. Ось важкоуловимі баги під час компіляції – це великі втрати часу на налагодження. Рецепт написаний за підсумком саме такого налагодження.

Обидва типи проблем легко вирішуються за допомогою npm overrides або yarn resolutions у package.json:
"typescript": "^5.0.2"
},
"overrides": {
"typescript": "$typescript"
}

$typescript каже npm перевикористовувати вказану версію для всіх пакетів. Тепер ваш код використовуватиме потрібну версію тайпскрипту під час компіляції.

Як швидко перейти на return await?
#eslint #typescript

Спочатку коротко розповім, навіщо це робити. Помилки в логах записуються у stack trace. Якщо функція повертає not resolved promise, то у stack trace буде дірка. Приклади коду та докладний розбір є у Node.js Best Practices 2.12 Always await promises before returning to avoid a partial stacktrace

Минулого тижня я занурився у debugging. Проблема була замаскована обірваними stack trace. Виявляється, що позбутися цього можна дуже швидко. Достатньо додати @typescript-eslint/return-await . Він має автофікс! Після eslint --fix дебаг втратив детективний сюжет, бо стало очевидним, що проблема у відсутності транзакцій на рівні бази даних. Так що додайте це правило до вашого проекту, щоб наступне налагодження пройшло швидше.

#typescript

На вихідних вийшла нова версія VSCode розширення pretty-ts-errors. Воно додає до вашого редактора:
👉 підсвічування синтаксису для типів у повідомленнях про помилки
👉 кнопка, яка відкриває оголошення відповідного типу поруч з типом у повідомленні про помилку.
👉 кнопка, яка відкриває помилку на typescript.tv
👉 кнопка, яка відкриває помилку на ts-error-translator

Якщо ви ще не користуєтеся цим розширенням, рекомендую встановити. pretty-ts-errors дуже спрощує роботу джунів та їх менторів.

Автор просить підтримати лайками додавання до VSCode необхідного API. Якщо ви віддаєте перевагу WebStorm, то ставте лайк JetBrains support. Будь ласка, ⚠️використовуйте лайк, а не коментарі⚠️ – це дозволить робити правильні метрики без спам сповіщень через коментар.

Посилання
🔗 source code
🔗 VSCode marketplace
🔗 upvotes to move forward

Як забезпечити іммутабельність у вашому коді?
#typescript
⚠️Уточнення для новачків іммутабельності це незмінність даних.
У заголовок винесено одне з моїх улюблених питань для співбесід. Наведу найкращу-гіршу відповідь як я почув її в оригіналі: "TypeScript provides readonly, but it is only compile-time immutable protection. So I prefer to use Immutable.js for my codebase. I've also used Object.freeze()"

Поясню чим саме ця відповідь погана для продуктової розробки: у продуктовому коді розробник має повний контроль усіх етапів створення, зміни та знищення даних. Це не код бібліотеки або фреймворку, який невідомо, як буде запущений. Це код продукту, який буде працювати повільніше через використання Immutable.js або Object.freeze().

TypeScript має відмінний функціонал:
➡️ readonly у параметрах інтерфейсів
➡️ генерік Readonly, який особливо зручний для аргументів ваших функцій
➡️ as const під час оголошення змінних

Цей функціонал покриває всі потреби продуктового коду і не впливає на run time. Для консистентності використання цих фічів є @typescript-eslint/prefer-readonly-parameter-types. Так же можливо написати свої eslint правила, щоб команда не забувала про readonly в іммутабельних структурах даних, наприклад DTO.

Щось таке я хотів би почути на інтерв'ю на вищеназване запитання. Це та ще трохи критики, що readonly як і інші TypeScript конструкції роблять код багатослівним та схожим на Java.