general

Author: SuperCat2812

docs/options/intro.md

@@ -1,12 +1,12 @@
 # Convenience vs. Soundness
 
-There are a few things that TypeScript prevents you from doing out of the box e.g. using a variable that *isn't ever declared* (of course you can use a *declaration file* for external systems).
+Є кілька речей, які TypeScript не дозволяє вам робити з коробки, наприклад. використовуючи змінну, яка *ніколи не оголошується* (звичайно, ви можете використовувати *файл декларації* для зовнішніх систем).
 
-That said, traditionally programming languages have a hard boundary between what is and isn't allowed by the type system. TypeScript is different in that it gives you control over where you put the slider. This is really to allow you to use the JavaScript you know and love with as much safety as **you** want. There are lots of compiler options to control exactly this slider so let's have a look.
+Тим не менш, традиційні мови програмування мають жорстку межу між тим, що дозволено і заборонено системою типів. TypeScript відрізняється тим, що він дає вам контроль над тим, де розмістити повзунок. Це дійсно для того, щоб дозволити вам використовувати JavaScript, який ви знаєте і любите, з такою безпечністю, як **Ви** хочете. Існує багато параметрів компілятора для керування саме цим повзунком, тому давайте подивимося.
 
 ## Boolean Options
 
-`compilerOptions` that are `boolean` can be specified as `compilerOptions` in `tsconfig.json`:
+`compilerOptions`, які є `boolean`, можна вказати як `compilerOptions` у `tsconfig.json`:
 
 ```json
 {
@@ -16,12 +16,12 @@ That said, traditionally programming languages have a hard boundary between what
 }
 ```
 
-or on the command line
+чи в командному рядку
 
 ```sh
 tsc --someBooleanOption
 ```
 
-> All of these are `false` by default.
+> Усе це за замовчуванням `false`.
 
-Click [here](https://www.typescriptlang.org/docs/handbook/compiler-options.html) to see all compiler options.
+Натисніть [тут](https://www.typescriptlang.org/docs/handbook/compiler-options.html), щоб переглянути всі параметри компілятора.

docs/options/noImplicitAny.md

@@ -1,34 +1,34 @@
 # noImplicitAny
 
-There are some things that cannot be inferred or inferring them might result in unexpected errors. A fine example is function arguments. If you don't annotate them, its unclear what should and shouldn't be valid e.g.
+Є деякі речі, про які неможливо зробити висновок, або їх висновок може призвести до несподіваних помилок. Гарним прикладом є аргументи функції. Якщо ви не анотуєте їх, незрозуміло, що має бути дійсним, а що ні.
 
 ```ts
 function log(someArg) {
   sendDataToServer(someArg);
 }
 
-// What arg is valid and what isn't?
+// Який аргумент вірний а який ні?
 log(123);
 log('hello world');
 ```
 
-So if you don't annotate some function argument, TypeScript assumes `any` and moves on. This essentially turns off type checking for such cases, which is what a JavaScript dev would expect. But this can catch people that want high safety off guard. Hence there is an option, `noImplicitAny`, that when switched on will flag the cases where the type cannot be inferred e.g.
+Отже, якщо ви не анотуєте якийсь аргумент функції, TypeScript припускає `any` і йде далі. По суті, це вимикає перевірку типу для таких випадків, чого очікував би розробник JavaScript. Але це може застати людей, які хочуть високої безпеки, зненацька. Таким чином, існує опція `noImplicitAny`, яка після ввімкнення позначатиме випадки, коли тип не можна визначити, наприклад.
 
 ```ts
 function log(someArg) { // Error : someArg has an implicit `any` type
   sendDataToServer(someArg);
 }
 ```
 
-Of course you can then go ahead and annotate:
+Звичайно, ви можете продовжити і описати:
 
 ```ts
 function log(someArg: number) {
   sendDataToServer(someArg);
 }
 ```
 
-And if you truly want *zero safety* you can mark it *explicitly* as `any`:
+І якщо ви справді бажаєте *нульової безпеки*, ви можете позначити його *явно* як `any`:
 
 ```ts
 function log(someArg: any) {

docs/options/strictNullChecks.md

@@ -1,23 +1,23 @@
 # `strictNullChecks`
 
-By default `null` and `undefined` are assignable to all types in TypeScript e.g.
+За замовчуванням `null` і `undefined` можна призначити всім типам у TypeScript, наприклад,
 
 ```ts
 let foo: number = 123;
 foo = null; // Okay
 foo = undefined; // Okay
 ```
 
-This is modelled after how a lot of people write JavaScript. However, like all things, TypeScript allows you to be *explicit* about what *can and cannot be* assigned a `null` or `undefined`.
+Це змодельовано за тим, як багато людей пишуть JavaScript. Однак, як і всі інші речі, TypeScript дозволяє *явно* визначити, чому *can and cannot be* присвоїти значення `null` або `undefined`.
 
-In strict null checking mode, `null` and `undefined` are different:
+У режимі суворої перевірки null `null` і `undefined` відрізняються:
 
 ```ts
 let foo = undefined;
 foo = null; // NOT Okay
 ```
 
-Let's say we have a `Member` interface:
+Скажімо, у нас є інтерфейс `Member`:
 
 ```ts
 interface Member {
@@ -26,29 +26,29 @@ interface Member {
 }
 ```
 
-Not every `Member` will provide their age, so `age` is an optional property, meaning the value of `age` may or may not be `undefined`.
+Не кожен `Member` вказує свій вік, тому `age` є необов'язковою властивістю, тобто значення `age` може бути або не бути `undefined`.
 
-`undefined` is the root of all evil. It often leads to runtime errors. It is easy to write code that will throw `Error` at runtime:
+`undefined` - це корінь усього зла. Це часто призводить до помилок виконання. Легко написати код, який видаватиме `Error` під час виконання:
 
 ```ts
 getMember()
   .then(member: Member => {
-    const stringifyAge = member.age.toString() // Cannot read property 'toString' of undefined
+    const stringifyAge = member.age.toString() // не можу примінити 'toString' к undefined
   })
 ```
 
-But in strict null checking mode, this error will be caught at compile time:
+Але в режимі суворої перевірки null ця помилка буде виявлена під час компіляції:
 
 ```ts
 getMember()
   .then(member: Member => {
-    const stringifyAge = member.age.toString() // Object is possibly 'undefined'
+    const stringifyAge = member.age.toString() // Об'єкт можливо 'undefined'
   })
 ```
 
 ## Non-Null Assertion Operator
 
-A new `!` post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. For example:
+Новий оператор постфіксованого виразу `!` може бути використаний для підтвердження того, що його операнд не є нульовим і не визначеним у контекстах, де перевірка типу не може зробити висновок про цей факт. Наприклад:
 
 ```ts
 // Compiled with --strictNullChecks
@@ -63,11 +63,11 @@ function processEntity(e?: Entity) {
 }
 ```
 
-> Note that it is just an assertion, and just like type assertions *you are responsible* for making sure the value is not null. A non-null assertion is essentially you telling the compiler "I know it's not null so let me use it as though it's not null".
+> Зауважте, що це лише твердження, і, як і твердження типу *ви відповідаєте* за те, щоб значення не було нульовим. Ненульове твердження, по суті, означає, що ви говорите компілятору: «Я знаю, що це не нуль, тому дозвольте мені використовувати його так, ніби воно не нульове».
 
 ### Definite Assignment Assertion Operator
 
-TypeScript will also complain about properties in classes not being initialized e.g.:
+TypeScript також скаржиться на неініціалізацію властивостей у класах, наприклад:
 
 ```ts
 class C {
@@ -80,7 +80,7 @@ class C {
 }
 ```
 
-You can use the definite assignment assertion postfixed to the property name to tell TypeScript that you are initializing it somewhere other than the constructor e.g.
+Ви можете використовувати твердження визначеного призначення, додане до назви властивості, щоб повідомити TypeScript, що ви ініціалізуєте його десь, крім конструктора, наприклад.
 
 ```ts
 class C {
@@ -98,7 +98,7 @@ class C {
 }
 ```
 
-You can also use this assertion with simple variable declarations e.g.:
+Ви також можете використовувати це твердження з простими оголошеннями змінних, наприклад:
 
 ```ts
 let a: number[]; // No assertion
@@ -115,4 +115,4 @@ function initialize() {
 }
 ```
 
-> Like all assertions, you are telling the compiler to trust you. The compiler will not complain even if the code doesn't actually always assign the property.
+> Як і всі твердження, ви говорите компілятору довіряти вам. Компілятор не скаржиться, навіть якщо код насправді не завжди призначає властивість.

docs/project/compilation-context.md

@@ -1,2 +1,2 @@
 ## Compilation Context
-The compilation context is basically just a fancy term for grouping of the files that TypeScript will parse and analyze to determine what is valid and what isn't. Along with the information about which files, the compilation context contains information about *which compiler options* are in use. A great way to define this logical grouping (we also like to use the term *project*) is using a `tsconfig.json` file.
+Контекст компіляції — це, по суті, просто модний термін для групування файлів, які TypeScript читати та аналізуватиме, щоб визначити, що є дійсним, а що ні. Разом з інформацією про те, які є файли, контекст компіляції містить інформацію про *які параметри компілятора* використовуються. Чудовий спосіб визначити це логічне групування (ми також любимо використовувати термін *project*) — це використовувати файл `tsconfig.json`.

docs/project/declarationspaces.md

@@ -1,48 +1,48 @@
 ## Declaration Spaces
 
-There are two declaration spaces in TypeScript: the *variable* declaration space and the *type* declaration space. These concepts are explored below.
+У TypeScript є два простори оголошень: простір оголошення *variable* і простір оголошення *type*. Ці поняття досліджуються нижче.
 
 ### Type Declaration Space
-The type declaration space contains stuff that can be used as a type annotation. E.g. the following are a few type declarations:
+Простір оголошення типу містить матеріал, який можна використовувати як анотацію типу. Наприклад нижче наведено кілька декларацій типів:
 
 ```ts
 class Foo {};
 interface Bar {};
 type Bas = {};
 ```
-This means that you can use `Foo`, `Bar`, `Bas`, etc. as a type annotation. E.g.:
+Це означає, що ви можете використовувати `Foo`, `Bar`, `Bas` як анотацію типу. Наприклад:
 
 ```ts
 var foo: Foo;
 var bar: Bar;
 var bas: Bas;
 ```
 
-Notice that even though you have `interface Bar`, *you can't use it as a variable* because it doesn't contribute to the *variable declaration space*. This is shown below:
+Зауважте, що навіть якщо у вас є `інтерфейс`, *ви не можете використовувати її як змінну*, оскільки вона не сприяє *простору оголошення змінних*. Це показано нижче:
 
 ```ts
 interface Bar {};
 var bar = Bar; // ERROR: "cannot find name 'Bar'"
 ```
 
-The reason why it says `cannot find name` is because the name `Bar` *is not defined* in the *variable* declaration space. That brings us to the next topic "Variable Declaration Space".
+Причина, чому він каже `не вдається знайти ім’я`, полягає в тому, що ім’я `Bar` *не визначено* у *просторі оголошення змінної*. Це підводить нас до наступної теми «Простір оголошення змінних».
 
 ### Variable Declaration Space
-The variable declaration space contains stuff that you can use as a variable. We saw that having `class Foo` contributes a type `Foo` to the *type* declaration space. Guess what? It also contributes a *variable* `Foo` to the *variable* declaration space as shown below:
+Простір оголошення змінної містить матеріал, який можна використовувати як змінну. Ми побачили, що наявність `class Foo` вносить тип `Foo` в простір оголошення *type*. Вгадай що? Він також додає *змінну* `Foo` до простору оголошення *змінної*, як показано нижче:
 
 ```ts
 class Foo {};
 var someVar = Foo;
 var someOtherVar = 123;
 ```
-This is great as sometimes you want to pass classes around as variables. Remember that:
+Це чудово, оскільки іноді ви хочете передати класи як змінні. Пам'ятайте, що:
 
-* we couldn't use something like an `interface` that is *only* in the *type* declaration space as a variable.
+* ми не могли використовувати щось на зразок `інтерфейсу`, який є *тільки* у просторі оголошення *type* як змінну.
 
-Similarly something that you declare with `var`, is *only* in the *variable* declaration space and cannot be used as a type annotation:
+Подібним чином те, що ви оголошуєте за допомогою `var`, знаходиться *тільки* в просторі оголошення *variable* і не може використовуватися як анотація типу:
 
 ```ts
 var foo = 123;
 var bar: foo; // ERROR: "cannot find name 'foo'"
 ```
-The reason why it says `cannot find name` is because the name `foo` *is not defined* in the *type* declaration space.
+Причина, чому написано `не вдається знайти ім’я`, полягає в тому, що ім’я `foo` *не визначено* у просторі оголошення *type*.