llhttp - new HTTP 1.1 parser for Node.js
#worth_seeing #typescript

На этой неделе в войс чате с Тимуром мы поднимали вопрос о системном программирование, т.е. создание инструментов для создания продуктов. Сегодняшний доклад как раз об этом.

В докладе Федор рассказывает как и зачем был переписан http_parser. Произошло это в 2019. Кодовая база http_parser на чистом С перестала быть поддерживаемой. Ее переписали на С + TypeScript и назвали llparse. Его исходный код стоит изучить с целью улучшения как своих навыков работы с TypeScript, так и понимания принципов работы http в целом.

Ссылки:
👀 Видео
📕 Сайт
⚙️ GitHub

Навіщо потрібне infer у TypeScript
#typescript

Ключове слово infer — це потужний інструмент, який дозволяє розгортати та зберігати типи під час роботи з чужим TypeScript кодом. Воно не може використовуватися без Conditional Types та поза пропозицією extends. Infer дозволяє визначити змінну в межах нашого обмеження, на яку буде посилатися або повертати.

наприклад, так можна отримати тип першого аргументу функції:
type GetFirstArgumentOfAnyFunction<T> = T extends (
first: infer FirstArgument,
...args: any[]
) => any
? FirstArgument
: never
Зверніть увагу, що описати це тільки через генерики неможливо.

Як змінити модифікатор TypeScript?
#typescript

Версія TypeScript 2.8 додала можливість додавати або видаляти складовим типам модифікатори readonly та ?. Для цього використовують очевидні оператори + і -. Детальніше в документації. Приклад використання:

interface ReadOnlyTodo {
readonly title: string
readonly description: string
readonly completed: boolean
}
type Mutable<T extends object> = {
-readonly [K in keyof T]: T[K]
}
type MutableTodo = Mutable<ReadOnlyTodo>

Рецепти на тему:
- Як підтягнути TypeScript?

​​Поділюся досвідом використання transform.tools. Частіше всього я використовую JSON To #TypeScript. Після трансформації можуть знадобитися правки, наприклад, додати enum. Приклади використання:
– додати інтерфейс події для Google Cloud Function. В ідеальному світі це вже повинно бути в SDK.
– описати інтерфейси запитів і відповідей для інтеграції зі стороннім API, у якому є текстова документація, але не специфікація. Якби була специфікація, наприклад Swagger, то правильно було б створити типи з неї.

Простий інструмент, який може заощадити час, тож про нього потрібно пам'ятати.

Як правильно налаштувати TypeScript?
#typescript

Більшість стартерів генерує неправильний tsconfig.json. Наприклад, після nest new project-name необхідно правильно налаштувати compilerOptions.target. Детальніше

Є такий репозиторій tsconfig/bases. З нього генеруються пакети виду @tsconfig/node18. Я рекомендую починати tsconfig.json із "extends": "@tsconfig/node18/tsconfig.json" і перевизначати тільки потрібні параметри. Для фанатів типізації можна використовувати @tsconfig/node18-strictest

Детальніше в репозиторії. Там, до речі, є і React.

SourceCode
#code_only #typescript

Які 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.