docs: update UA readme

README.ukrainian.md

@@ -380,157 +380,153 @@ Read in a different language: [![CN](./assets/flags/CN.png)**CN**](./README.chin
 
 **В іншому випадку:** Уявіть таку ситуацію – ваша функція очікує числовий аргумент "Знижка", який викликаюча сторона забуває передати, потім ваш код перевіряє, чи Знижка!=0 (розмір дозволеної знижки більший ніж нуль), тоді він дозволить користувачу отримати знижку. О боже, яка неприємна помилка. Бачите її?
 
-🔗 [**Читати більше: швидке виявлення помилок**](./sections/errorhandling/failfast.md)
+🔗 [**Читати більше: швидке виявлення помилок**](./sections/errorhandling/failfast.ukrainian.md)
 
 <br/><br/>
 
-## ![✔] 2.12 Always await promises before returning to avoid a partial stacktrace
+## ![✔] 2.12 Завжди очікуйте проміси перед поверненням, щоб уникнути часткового стеку викликів
 
-**TL;DR:** Always do `return await` when returning a promise to benefit full error stacktrace. If a
-function returns a promise, that function must be declared as `async` function and explicitly
-`await` the promise before returning it
+**Коротко:** Завжди використовуйте `return await` при поверненні промісу, щоб отримати повний стек помилок. Якщо функція повертає проміс, ця функція повинна бути оголошена як `async` функція і явно використовувати `await` для промісу перед його поверненням
 
-**Otherwise:** The function that returns a promise without awaiting won't appear in the stacktrace.
-Such missing frames would probably complicate the understanding of the flow that leads to the error,
-especially if the cause of the abnormal behavior is inside of the missing function
+**В іншому випадку:** Функція, яка повертає проміс без очікування, не з'явиться у стеку викликів. Такі відсутні кадри, ймовірно, ускладнять розуміння потоку, що призвів до помилки, особливо якщо причина аномальної поведінки знаходиться всередині відсутньої функції
 
-🔗 [**Read More: returning promises**](./sections/errorhandling/returningpromises.md)
+🔗 [**Читати більше: повернення промісу**](./sections/errorhandling/returningpromises.ukrainian.md)
 
 <br/><br/><br/>
 
 <p align="right"><a href="#table-of-contents">⬆ Return to top</a></p>
 
 # `3. Code Style Practices`
 
-## ![✔] 3.1 Use ESLint
+## ![✔] 3.1 Використовуйте ESLint
 
-**TL;DR:** [ESLint](https://eslint.org) is the de-facto standard for checking possible code errors and fixing code style, not only to identify nitty-gritty spacing issues but also to detect serious code anti-patterns like developers throwing errors without classification. Though ESLint can automatically fix code styles, other tools like [prettier](https://www.npmjs.com/package/prettier) and [beautify](https://www.npmjs.com/package/js-beautify) are more powerful in formatting the fix and work in conjunction with ESLint
+**Коротко:** [ESLint](https://eslint.org) є фактичним стандартом для перевірки можливих помилок у коді та виправлення стилю коду. Він допомагає не лише виявити дрібні проблеми зі структурою коду, такі як зайві пробіли, але й серйозні антипатерни коду, наприклад, коли розробники кидають помилки без класифікації. Хоча ESLint може автоматично виправляти стиль коду, інші інструменти, такі як [prettier](https://www.npmjs.com/package/prettier) і [beautify](https://www.npmjs.com/package/js-beautify), більш потужні у форматуванні виправлень і працюють разом з ESLint.
 
-**Otherwise:** Developers will focus on tedious spacing and line-width concerns and time might be wasted overthinking the project's code style
+**В іншому випадку:** Розробники зосереджуватимуться на нудних питаннях щодо пробілів та ширини рядків, а час може бути витрачено на надмірне обдумування стилю коду проєкту.
 
-🔗 [**Read More: Using ESLint and Prettier**](./sections/codestylepractices/eslint_prettier.md)
+🔗 [**Детальніше: Використання ESLint та Prettier**](./sections/codestylepractices/eslint_prettier.ukrainian.md)
 
 <br/><br/>
 
-## ![✔] 3.2 Node.js specific plugins
+## ![✔] 3.2 Специфічні плагіни для Node.js
 
-**TL;DR:** On top of ESLint standard rules that cover vanilla JavaScript, add Node.js specific plugins like [eslint-plugin-node](https://www.npmjs.com/package/eslint-plugin-node), [eslint-plugin-mocha](https://www.npmjs.com/package/eslint-plugin-mocha) and [eslint-plugin-node-security](https://www.npmjs.com/package/eslint-plugin-security)
+**Коротко:** Окрім стандартних правил ESLint, що охоплюють ванільний JavaScript, додайте специфічні плагіни для Node.js, такі як [eslint-plugin-node](https://www.npmjs.com/package/eslint-plugin-node), [eslint-plugin-mocha](https://www.npmjs.com/package/eslint-plugin-mocha) і [eslint-plugin-node-security](https://www.npmjs.com/package/eslint-plugin-security).
 
-**Otherwise:** Many faulty Node.js code patterns might escape under the radar. For example, developers might require(variableAsPath) files with a variable given as a path which allows attackers to execute any JS script. Node.js linters can detect such patterns and complain early
+**Інакше:** Багато проблемних шаблонів коду Node.js можуть залишитися непоміченими. Наприклад, розробники можуть використовувати require(variableAsPath) для підключення файлів з передачею змінної як шляху, що дозволяє зловмисникам виконувати будь-який JS-скрипт. Лінтери Node.js можуть виявляти такі шаблони та попереджати про них заздалегідь.
 
 <br/><br/>
 
-## ![✔] 3.3 Start a Codeblock's Curly Braces on the Same Line
+## ![✔] 3.3 Відкривайте фігурні дужки коду на тому ж рядку
 
-**TL;DR:** The opening curly braces of a code block should be on the same line as the opening statement
+**Коротко:** Відкриваючі фігурні дужки блоку коду повинні бути на тому ж рядку, що й оператор відкриття.
 
-### Code Example
+### Приклад коду
 
 ```javascript
-// Do
+// Правильно
 function someFunction() {
-  // code block
+  // блок коду
 }
 
-// Avoid
+// Уникайте
 function someFunction()
 {
-  // code block
+  // блок коду
 }
 ```
 
-**Otherwise:** Deferring from this best practice might lead to unexpected results, as seen in the StackOverflow thread below:
+**Інакше:** Відхилення від цієї практики може призвести до несподіваних результатів, як показано в обговоренні на StackOverflow нижче:
 
-🔗 [**Read more:** "Why do results vary based on curly brace placement?" (StackOverflow)](https://stackoverflow.com/questions/3641519/why-does-a-results-vary-based-on-curly-brace-placement)
+🔗 [**Читати більше:** "Чому результати варіюються залежно від розміщення фігурних дужок?" (StackOverflow)](https://stackoverflow.com/questions/3641519/why-does-a-results-vary-based-on-curly-brace-placement)
 
 <br/><br/>
 
-## ![✔] 3.4 Separate your statements properly
+## ![✔] 3.4 Правильно розділяйте свої вирази
 
-No matter if you use semicolons or not to separate your statements, knowing the common pitfalls of improper linebreaks or automatic semicolon insertion, will help you to eliminate regular syntax errors.
+Незалежно від того, використовуєте ви крапки з комами для розділення виразів чи ні, знання поширених помилок, пов'язаних з неправильними розривами рядків або автоматичною вставкою крапок з комами, допоможе уникнути регулярних синтаксичних помилок.
 
-**TL;DR:** Use ESLint to gain awareness about separation concerns. [Prettier](https://prettier.io/) or [Standardjs](https://standardjs.com/) can automatically resolve these issues.
+**Коротко:** Використовуйте ESLint для підвищення обізнаності про проблеми з розділенням виразів. [Prettier](https://prettier.io/) або [Standardjs](https://standardjs.com/) можуть автоматично вирішити ці проблеми.
 
-**Otherwise:** As seen in the previous section, JavaScript's interpreter automatically adds a semicolon at the end of a statement if there isn't one, or considers a statement as not ended where it should, which might lead to some undesired results. You can use assignments and avoid using immediately invoked function expressions to prevent most of the unexpected errors.
+**Інакше:** Як було показано в попередньому розділі, інтерпретатор JavaScript автоматично додає крапку з комою в кінці виразу, якщо її немає, або вважає, що вираз не завершено там, де це потрібно, що може призвести до небажаних результатів. Ви можете використовувати присвоєння і уникати безпосередньо викликаних функціональних виразів (IIFE), щоб уникнути більшості несподіваних помилок.
 
-### Code example
+### Приклад коду
 
 ```javascript
-// Do
+// Правильно
 function doThing() {
     // ...
 }
 
 doThing()
 
-// Do
+// Правильно
 
 const items = [1, 2, 3]
 items.forEach(console.log)
 
-// Avoid — throws exception
+// Неправильно — виникає виняток
 const m = new Map()
 const a = [1,2,3]
 [...m.values()].forEach(console.log)
 > [...m.values()].forEach(console.log)
 >  ^^^
 > SyntaxError: Unexpected token ...
 
-// Avoid — throws exception
-const count = 2 // it tries to run 2(), but 2 is not a function
+// Неправильно — виникає виняток
+const count = 2 // інтерпретатор намагається виконати 2(), але 2 не є функцією
 (function doSomething() {
-  // do something amazing
+  // зробити щось чудове
 }())
-// put a semicolon before the immediate invoked function, after the const definition, save the return value of the anonymous function to a variable or avoid IIFEs altogether
+// вставте крапку з комою перед безпосередньо викликаним виразом, після визначення const, збережіть результат анонімної функції у змінну або уникайте IIFE взагалі
 ```
 
-🔗 [**Read more:** "Semi ESLint rule"](https://eslint.org/docs/rules/semi)
-🔗 [**Read more:** "No unexpected multiline ESLint rule"](https://eslint.org/docs/rules/no-unexpected-multiline)
+🔗 [**Читати більше:** "Правило ESLint для крапок з комами"](https://eslint.org/docs/rules/semi)  
+🔗 [**Читати більше:** "Правило ESLint для несподіваних розривів рядків"](https://eslint.org/docs/rules/no-unexpected-multiline)
 
 <br/><br/>
 
-## ![✔] 3.5 Name your functions
+## ![✔] 3.5 Давайте імена своїм функціям
 
-**TL;DR:** Name all functions, including closures and callbacks. Avoid anonymous functions. This is especially useful when profiling a node app. Naming all functions will allow you to easily understand what you're looking at when checking a memory snapshot
+**Коротко:** Давайте імена всім функціям, включно із замиканнями та зворотними викликами. Уникайте анонімних функцій. Це особливо корисно при профілюванні Node.js додатків. Присвоєння імен функціям дозволить вам легко розуміти, що ви переглядаєте під час аналізу знімку пам'яті.
 
-**Otherwise:** Debugging production issues using a core dump (memory snapshot) might become challenging as you notice significant memory consumption from anonymous functions
+**Інакше:** Виправлення проблем на продакшені за допомогою core dump (знімка пам'яті) може стати складним завданням, оскільки ви можете помітити значне споживання пам'яті анонімними функціями.
 
 <br/><br/>
 
-## ![✔] 3.6 Use naming conventions for variables, constants, functions and classes
+## ![✔] 3.6 Використовуйте угоди про іменування для змінних, констант, функцій і класів
 
-**TL;DR:** Use **_lowerCamelCase_** when naming constants, variables and functions, **_UpperCamelCase_** (capital first letter as well) when naming classes and **_UPPER_SNAKE_CASE_** when naming global or static variables. This will help you to easily distinguish between plain variables, functions, classes that require instantiation and variables declared at global module scope. Use descriptive names, but try to keep them short
+**Коротко:** Використовуйте **_lowerCamelCase_** для називання констант, змінних і функцій, **_UpperCamelCase_** (перша велика літера) для називання класів і **_UPPER_SNAKE_CASE_** для називання глобальних або статичних змінних. Це допоможе легко розрізняти звичайні змінні, функції, класи, які потребують інстанціювання, та змінні, оголошені на рівні глобального модуля. Використовуйте описові імена, але намагайтеся робити їх короткими.
 
-**Otherwise:** JavaScript is the only language in the world that allows invoking a constructor ("Class") directly without instantiating it first. Consequently, Classes and function-constructors are differentiated by starting with UpperCamelCase
+**Інакше:** JavaScript — єдина мова у світі, яка дозволяє викликати конструктор ("Клас") напряму без попередньої інстанціювання. Як наслідок, класи та функції-конструктори відрізняються тим, що починаються з UpperCamelCase.
 
-### 3.6 Code Example
+### 3.6 Приклад коду
 
 ```javascript
-// for global variables names we use the const/let keyword and UPPER_SNAKE_CASE
+// для глобальних змінних використовуємо ключові слова const/let і UPPER_SNAKE_CASE
 let MUTABLE_GLOBAL = "mutable value"
 const GLOBAL_CONSTANT = "immutable value";
 const CONFIG = {
   key: "value",
 };
 
-// examples of UPPER_SNAKE_CASE convention in nodejs/javascript ecosystem
-// in javascript Math.PI module
+// приклади угоди UPPER_SNAKE_CASE у екосистемі nodejs/javascript
+// у модулі JavaScript Math.PI
 const PI = 3.141592653589793;
 
 // https://github.com/nodejs/node/blob/b9f36062d7b5c5039498e98d2f2c180dca2a7065/lib/internal/http2/core.js#L303
-// in nodejs http2 module
+// у модулі nodejs http2
 const HTTP_STATUS_OK = 200;
 const HTTP_STATUS_CREATED = 201;
 
-// for class name we use UpperCamelCase
+// для назв класів використовуємо UpperCamelCase
 class SomeClassExample {
-  // for static class properties we use UPPER_SNAKE_CASE
+  // для статичних властивостей класів використовуємо UPPER_SNAKE_CASE
   static STATIC_PROPERTY = "value";
 }
 
-// for functions names we use lowerCamelCase
+// для назв функцій використовуємо lowerCamelCase
 function doSomething() {
-  // for scoped variable names we use the const/let keyword and lowerCamelCase
+  // для локальних змінних використовуємо ключові слова const/let і lowerCamelCase
   const someConstExample = "immutable value";
   let someMutableExample = "mutable value";
 }

sections/codestylepractices/eslint_prettier.ukrainian.md

@@ -0,0 +1,25 @@
+# Використання ESLint та Prettier
+
+### Порівняння ESLint та Prettier
+
+Якщо ви відформатуєте цей код за допомогою ESLint, він лише видасть попередження про те, що рядок занадто широкий (залежить від налаштувань `max-len`). Prettier автоматично відформатує його для вас.
+
+```javascript
+foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne(), noWayYouGottaBeKiddingMe());
+```
+
+```javascript
+foo(
+    reallyLongArg(),
+    omgSoManyParameters(),
+    IShouldRefactorThis(),
+    isThereSeriouslyAnotherOne(),
+    noWayYouGottaBeKiddingMe()
+);
+```
+
+Джерело: [https://github.com/prettier/prettier-eslint/issues/101](https://github.com/prettier/prettier-eslint/issues/101)
+
+### Інтеграція ESLint та Prettier
+
+ESLint та Prettier перетинаються у функції форматування коду, але їх можна легко поєднати за допомогою інших пакетів, таких як [prettier-eslint](https://github.com/prettier/prettier-eslint), [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) та [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier). Для отримання додаткової інформації про їхні відмінності, ви можете переглянути посилання [тут](https://stackoverflow.com/questions/44690308/whats-the-difference-between-prettier-eslint-eslint-plugin-prettier-and-eslint).