DEV Community: Barin Britva

TypeScript: Sorting out tsconfig. Part 2

Barin Britva — Thu, 12 Aug 2021 11:07:03 +0000

TypeScript: Sorting out `tsconfig`. Part 2

In the previous article, I covered a number of quirks in TypeScript’s general settings. This one is about the so-called “strictness flags.”

Out of the box, TypeScript is not very different from JavaScript. Unless you tune the project config from the start, most of the language’s advantages never come into play. There is some point in using TypeScript that way, but not much.

If I had to reduce this entire article to one sentence, it would be this: open tsconfig.json and set strict to true under compilerOptions. Without strict mode, TypeScript is almost a waste of time. Still, neither the previous article nor this one is meant to tell you the one “right” way to do things. The goal is to clarify the finer points of configuration. So let’s get into it.

In the official tsconfig.json reference, its many options are split into sections. Two of them, Strict Checks and Linter Checks, contain only strictness flags. A few more flags relevant today are tucked away in the largest option group: Advanced.

The `Strict Checks` group

These are probably the most important flags of the lot: strict, alwaysStrict, noImplicitAny, strictNullChecks, strictFunctionTypes, strictPropertyInitialization, noImplicitThis, and strictBindCallApply.

Every flag above defaults to false. To make things strict, set it to the opposite value: true.

Looking at the list, the similarly named strict and alwaysStrict flags can be confusing. In reality, they do completely different jobs.

`alwaysStrict`

Recommended: always / difficulty: easy.

alwaysStrict adds the "use strict" directive to every compiled file. In other words, it enables JavaScript strict mode. It has nothing to do with TypeScript type checking.

`strict`

Recommended: always / difficulty: hard / can be replaced by a set of other flags.

strict is directly related to type checking. Enabling it automatically turns on every flag in Strict Checks, including alwaysStrict. That is exactly what I was talking about at the beginning.

This approach has at least one downside: it is opaque. When you set strict: true, you cannot immediately see exactly which checks are enabled or which options exist at all. For projects written in TypeScript from day one, this matters less than it does for projects being migrated gradually from JavaScript.

When migrating an existing application, you cannot switch on every check at once. You have to enable them one by one, step by step. Sometimes problems even force you to roll previously enabled flags back to false.

There is one small detail about strict: its controlled list of flags can grow as new TypeScript versions are released. That does not happen often, and it is always covered in the release notes, assuming that you read them before updating.

Personally, I prefer to list the flags explicitly:

{
  "compilerOptions": {
    "alwaysStrict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "strictFunctionTypes": true,
    "noImplicitThis": true,
    "strictBindCallApply": true,
  }
}

Let’s look at what each flag does, and discuss which ones to enable first if turning them all on at once is not an option.

`noImplicitAny`

Recommended: always / difficulty: medium.

This is the first flag you should enable when starting a TypeScript project.

First, a word about any. It is a special type assigned to every variable whose type was not stated explicitly and cannot be inferred automatically by the compiler. It exists for JavaScript compatibility. From TypeScript’s point of view, every JavaScript variable is any, because JavaScript has no type system.

To the compiler, any means: “This can be anything. I am handing control and responsibility to the developer.” Because it does not know the variable’s type, you can do absolutely anything with such a variable. This is where TypeScript loses all of its power:

// type stated explicitly
let a: number = 5
// type inferred
let b = 'hello'
// type is not stated and cannot be inferred
// value will be implicitly declared as any
function someFunction (value) {
  // so the error on this line goes unnoticed
  console.log(value.subtr(3))
}

Put differently, if a variable’s type is unknown, it is any. If it is any, this is JavaScript rather than TypeScript code. So the number of unspecified types in a codebase is a real measure of the ratio between its TypeScript and JavaScript. noImplicitAny highlights every such spot so the developer does not forget to state types.

That does not mean you can no longer use any at all. It only means that in such cases the developer must write any explicitly if, for some reason, the variable cannot be typed correctly, or if typing it causes errors elsewhere in the code.

// explicitly mark code as potentially unsafe with any
function someFunction (value: any) {
  console.log(value.subtr(3))
}

An explicit any reminds the developer that this code is unfinished and that these places need improvement over time. That is the point of noImplicitAny.

You can reinforce this with ESLint’s no-explicit-any rule. It marks uses of any as warnings, drawing a developer’s attention to them every time.

`strictNullChecks`

Recommended: always / difficulty: medium.

This flag enables one of TypeScript’s most powerful features. I recommend turning it on immediately after noImplicitAny.

JavaScript has two bottom values, undefined and null, and TypeScript has types with the same names. In the type hierarchy, every other type is considered to derive from them. By inheritance, a value of undefined or null can be passed in place of a variable of any type: string, boolean, number, and so on.

function someFunction (value: number) {
  // may produce an unexpected result if value is undefined or null
  return value * 2
}
someFunction(5)
// this is allowed by default
someFunction(null)
// and so is this
someFunction(undefined)

This behavior is true of most, if not all, programming languages. In practice, it can be inconvenient because it requires extra null/undefined checks. The much bigger problem is remembering that your code needs those checks. Java developers, with their NullPointerException, understand this better than anyone.

Enabling strictNullChecks changes the rules of the game. With it on, the compiler no longer lets you pass undefined or null where another type is expected unless you explicitly allow it:

function someFunction (value: number) {
  // value will always be a number
  return value * 2
}
someFunction(5)
// the following function calls are not allowed
someFunction(null)
someFunction(undefined)

That means you do not have to handle undefined and null in code where those values cannot occur. Where they can occur, the compiler will not let you forget the checks. This is a powerful mechanism whose value is hard to overstate.

// “?” permits undefined, and “| null” permits null
function someFunction (value?: number | null) {
  if (value == null) {
    return 0
  }
  return value * 2
}

There is only one potentially dangerous point. Everything works perfectly in our statically typed code. But applications often work with dynamically received data, such as data from a server, whose declared types may not match reality at all. In other words, the types say a value cannot be null, but the server sends it anyway. You can avoid this by making validation of server responses standard practice, for example with JSON Schema validators.

External libraries can be a little more treacherous. In particular, libraries originally written in JavaScript whose typings are maintained separately from the code. In those cases, mismatches between the real code and its types can produce exactly the situation described above.

Here is a compatibility table for types with strictNullChecks on and off: Any, unknown, object, void, undefined, null and never assignability.

`strictPropertyInitialization`

Recommended: always / difficulty: easy / related to strictNullChecks.

strictPropertyInitialization ensures that declared class properties are always initialized:

class User {
  name: string
  // email is initialized neither here nor in the constructor
  // the compiler will tell us that a value must be set
  email: string
  constructor (name: string) {
    this.name = name
  }
}

This option is a kind of companion to strictNullChecks, so it works only when that flag is also enabled.

`strictFunctionTypes`

Recommended: always / difficulty: easy.

Setting strictFunctionTypes: true enables stricter checking of function signatures. Overall, this option looks like an obvious must-have:

interface StringOrNumberFunc {
  (value: string | number): void
}
function someFunction (value: string) {
  console.log(value)
}
// the signatures do not match
// string | number is not equivalent to string
let func: StringOrNumberFunc = someFunction
func(10)
func('10')

`noImplicitThis`

Recommended: always / difficulty: easy.

When you use this, this flag checks that the execution context is known. Consider this example:

class SomeClass {
  multiplier: number = 5
  createSomeFunction (value: number) {
    return function () {
      // context is lost: this is NOT a SomeClass instance here
      return value * this.multiplier
    }
  }
}

The this object is unknown because function does not pass the context through automatically. Here you can fix it by replacing function with an arrow function.

Consider a standalone function that, for some reason, must use an external this:

function sayHello (name: string) {
  console.log(this.helloWord + ' ' + name)
}

Here, too, this is unknown. You can run a function with an external this using bind, call, or apply. You can teach the function about its context like this:

// state the this type as the first “argument”
// in practice, it is not counted as a function argument
function sayHello (this: HelloStyle, name: string) {
  console.log(this.helloWord + ' ' + name)
}
// declare greeting variants
interface HelloStyle {
  helloWord: string
}
class HawaiiStyle implements HelloStyle {
  helloWord = 'Aloha'
}
class RussianStyle implements HelloStyle {
  helloWord = 'Привет,'
}
// now call it
sayHello.bind(new HawaiiStyle())('World')
sayHello.call(new RussianStyle(), 'World')
sayHello.apply(new RussianStyle(), ['World'])

In every case, the context type is known, and even editor type hints work as they should.

`strictBindCallApply`

Recommended: always / difficulty: medium.

strictBindCallApply enables stricter signature checks for the corresponding methods: bind, call, and apply.

function someFunction (value: string) {
  console.log(value)
}
someFunction.call(undefined, '10')
// yes, cases like this need a separate flag
someFunction.call(undefined, false)

Apart from a few specialized cases, this flag does not cause problems. If a difficult case does arise, I recommend disabling the check at the problem location with // @ts-ignore rather than turning the rule off entirely.

`Strict Checks`: summary

Every flag here really is useful. Together they let TypeScript reach its potential and deliver the most value.
You can enable them all with strict: true, or enable each one separately. The latter is ideal for mixed codebases where some code has not yet been converted to TypeScript.
alwaysStrict is not about TypeScript strict mode. It is about JavaScript strict mode, that is, "use strict".
The top priorities are noImplicitAny and strictNullChecks together with strictPropertyInitialization. Next come strictFunctionTypes and noImplicitThis. strictBindCallApply comes last.

The `Linter Checks` group

The name speaks for itself: these flags are meant to check code quality rather than type compatibility. They are rules of the same kind as ESLint’s. Some Linter Checks rules can indeed be replaced with their ESLint equivalents. The full list is:

{
  "compilerOptions": {
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
  }
}

Every flag above defaults to false. To make things strict, set it to the opposite value: true.

I deliberately separated noPropertyAccessFromIndexSignature and noUncheckedIndexedAccess from the other flags with a blank line. They are here only because conceptually they cannot live in Strict Checks. That section is intended for flags controlled by strict.

But these flags are too specific to enable by default. That is more or less what the announcements for noPropertyAccessFromIndexSignature and noUncheckedIndexedAccess say. Still, that does not make them lint rules. They check types and really belong to Strict Checks, but they are not enabled automatically by strict.

The remaining flags are full citizens of this section and have analogous ESLint rules. There are a few temporary limitations, since not every rule has been moved from TSLint to ESLint yet. You can see the rule mappings in the TSLint Migration Guide and the ESLint rules for TSLint repository.

Let’s look at each flag.

`noPropertyAccessFromIndexSignature`

Recommended: always / difficulty: easy / one caveat / cannot be replaced by a linter.

noPropertyAccessFromIndexSignature forbids accessing an object property with a dot, also known as dot notation, when the property is not declared explicitly but through arbitrarily named properties (index signatures).

interface User {
  // explicitly declared properties
  login: string
  email: string
  // arbitrary properties
  [key: string]: string
}
const user: User = {
  login: 'hello',
  email: 'hello@example.com'
}
// with noPropertyAccessFromIndexSignature: true
// this line produces an error
const username = user.name
// but this access is still allowed
const username2 = user['name']

Instead of dot notation, we use bracket notation. The idea is much the same as with noImplicitAny: draw attention to potentially troublesome places.

The only reason not to use this option is that you end up with two syntaxes for property access. In my view, that is not a problem. While the syntaxes differ, each has its purpose. Always use dot notation. If an exception comes up, switch to bracket notation. The result is safer code, so I recommend this flag.

There is one more reason, but noUncheckedIndexedAccess addresses it.

`noUncheckedIndexedAccess`

Recommended: case by case / difficulty: medium / serious caveat / related to strictNullChecks / cannot be replaced by a linter.

Let’s look at the previous example again.

interface User {
  // explicitly declared properties
  login: string
  email: string
  // arbitrary properties
  [key: string]: string
}
const user: User = {
  login: 'hello',
  email: 'hello@example.com'
}
// the username variable has type string
const username = user['name']

As we can see, username has type string. That is not quite right, since we can access any property, even one that does not exist. You could declare arbitrary fields as [key: string]: string | undefined. That solves the problem, but creates manual work. Plus, people will occasionally forget to add undefined.

noUncheckedIndexedAccess does that work for us. The compiler will no longer let you use a variable obtained this way without checking it first.

Here is another example, this time with an array:

const strings: string[] = ['hello']
// here, number will have type string
const number = strings[100]

Obviously, the variable is undefined here. With noUncheckedIndexedAccess enabled, its type in cases like this becomes string | undefined.

It seems perfect: bracket notation marks the object’s “magic” properties. We can use them only after checking for undefined. Everything is safe. What could go wrong?

In short:

const strings: string[] = ['hello']
// here too, number will have type string | undefined
const number = strings[0]

Or:

function upperCaseAll(strings: string[]) {
  for (let i = 0; i < strings.length; i++) {
      // this causes a compilation error
      console.log(strings[i].toUpperCase());
  }
}

In other words, with this configuration you gain safety, but in some cases pay for it with checks that make no sense, solely to tame a stubborn compiler. It feels very much like a workaround.

Code with noUncheckedIndexedAccess is definitely much safer, and that is TypeScript’s main purpose. But the trade-off can be substantial, so I cannot recommend the flag to everyone.

This flag is a kind of companion to strictNullChecks, so it works only when that flag is also enabled.

`noImplicitReturns`

Recommended: always / difficulty: easy / ESLint rule: consistent-return, not implemented yet.

This flag ensures every branch of a function returns a value:

function lookupHeadphonesManufacturer(color: 'blue' | 'black'): string {
  if (color === 'blue') {
    return 'beats'
  }
  // forgot return
}

It is analogous to ESLint’s consistent-return, which at the time was not yet implemented for TypeScript.

`noFallthroughCasesInSwitch`

Recommended: if you do not use ESLint / difficulty: easy / ESLint rule: no-fallthrough.

This flag checks for break in a switch/case statement:

switch (value) {
  case 0:
    console.log('even')
    // forgot break
  case 1:
    console.log('odd')
    break
}

It can be replaced by no-fallthrough.

`noUnusedLocals`

Recommended: for production if you do not use ESLint / difficulty: easy / ESLint rule: no-unused-vars.

The code is checked for unused variables:

function createKeyboard (modelID: number) {
  // an unused variable is declared
  const defaultModelID = 23
  return {
    type: 'keyboard',
    modelID
  }
}

This rule is extremely inconvenient during development. While you are writing code, it may be in pieces, and unused variables will cause compilation errors.

You can override the flag for a development environment or use ESLint’s no-unused-vars.

`noUnusedParameters`

Recommended: for production if you do not use ESLint / difficulty: easy / ESLint rule: no-unused-vars.

The code is checked for unused function and method arguments:

function createDefaultKeyboard (modelID: number) {
  const defaultModelID = 23
  return {
    type: 'keyboard',
    modelID: defaultModelID
  }
}

Like noUnusedParameters, this rule gets in the way of a comfortable development process. You can override it for development, or add arguments settings to ESLint’s no-unused-vars.

`Linter Checks`: summary

There is no single flag that turns on every option in the section.
noPropertyAccessFromIndexSignature and noUncheckedIndexedAccess are really Strict Checks. They are just not automatically enabled by the main strict flag.
The other flags, noFallthroughCasesInSwitch, noUnusedLocals, and noUnusedParameters, can be replaced by linter rules. The rule for noImplicitReturns was only temporarily unsupported.

The `Advanced` group

This is the largest section. It looks as though every option that did not fit a separate group was put here. Some of its options concern compiler strictness:

{
  "compilerOptions": {
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "noImplicitUseStrict": false,
    "suppressExcessPropertyErrors": false,
    "suppressImplicitAnyIndexErrors": false,
    "noStrictGenericChecks": false,
  }
}

allowUnreachableCode and allowUnusedLabels are separated by a blank line for a reason: they escaped from Linter Checks.

Surprisingly, these flags default to true, while strictness requires false. That is the exact opposite.

It is easy enough to remember. Earlier options of this kind used the no prefix: “forbid the allowance.” These use allow: “permit the allowance.” For consistency, they ought to be renamed noUnreachableCode and noUnusedLabels and sent to the appropriate group.

The remaining flags, noImplicitUseStrict, noStrictGenericChecks, suppressExcessPropertyErrors, and suppressImplicitAnyIndexErrors, could form a new group called Base Strict Checks. Here is why:

These flags default to false and should remain false for strictness!

So we have found the options enabled by default that make up TypeScript’s out-of-the-box type safety.

In essence, the options above (except noImplicitUseStrict) permit explicit violations of typing. That can sometimes serve as a temporary measure while migrating difficult JavaScript code.

In 99.9% of cases, you will never need to override any of these four flags.

Now, a few words about this pseudo-group.

`allowUnreachableCode`

Recommended: always for production / difficulty: easy / ESLint rule: no-unreachable, not implemented yet.

This flag forbids unreachable code: code written after return, throw, break, or continue.

function fn (n: number) {
  if (n > 5) {
    return true
  } else {
    return false
  }
  // unreachable code
  return true
}

It is convenient to disable this flag during development. It is analogous to ESLint’s no-unreachable, which at the time was not implemented for TypeScript.

`allowUnusedLabels`

Recommended: for production if you do not use ESLint / difficulty: easy / ESLint rule: no-unused-labels.

This option forbids unused labels. I do not think you will find this construct in the wild nowadays, but still:

function verifyAge (age: number) {
  if (age > 18) {
    // that very unused label
    verified: true
  }
}

Replace it with ESLint’s no-unused-labels.

`noImplicitUseStrict`

Configured by default. Do not change it / related to alwaysStrict.

This flag automatically adds "use strict" when target is lower than ES6. alwaysStrict does the same for every target. It is hard to imagine ever needing to override this flag.

If both noImplicitUseStrict and alwaysStrict are set to true, compilation fails because the settings conflict.

`suppressExcessPropertyErrors`

Configured by default. Do not change it.

This flag ensures an object cannot contain properties that were not described in its structure:

interface Point {
  x: number
  y: number
}
const p: Point = {
  x: 1,
  y: 3,
  // property z is not declared in the Point interface
  z: 10
}

You can temporarily switch this setting off while migrating a JavaScript codebase if it has many such cases. But restore the original value afterward. For one-off cases, // @ts-ignore is better.

`suppressImplicitAnyIndexErrors`

Configured by default. Do not change it / related to noImplicitAny.

This flag checks that bracket notation cannot access object properties which are not declared explicitly or through arbitrary properties. Recall the noUncheckedIndexedAccess example and remove its arbitrary properties:

interface User {
  // explicitly declared properties
  login: string
  email: string
  // comment out the arbitrary properties
  // [key: string]: string
}
const user: User = {
  login: 'hello',
  email: 'hello@example.com'
}
// name can no longer be accessed
const username = user['name']

It might seem that no other behavior is possible. But, as I said, the final four flags can sometimes permit a type-system violation for edge cases. For example, this flag is often inverted when people do not know how to extend TypeScript’s built-in typings or third-party typings. That is bad practice. The right tool is declaration merging.

For example, suppose we load Google Maps through a script tag and try to create a Pin:

const pin = new window.google.maps.Pin(59.9386, 30.3141)

Naturally, this errors because the built-in typings know nothing about google. // @ts-ignore is awkward because you would need it on almost every line. So you will often see this solution: set suppressImplicitAnyIndexErrors: true (allow the escape hatch) and write:

const pin = new window['google']['maps']['Pin'](59.9386, 30.3141)

That can exist in projects halfway through a migration. Still, I would not recommend it even there. Declaration merging solves the problem:

// an arbitrary merging.d.ts file
interface Pin {
  // declaration
}
interface PinConstructor {
  new(lat: number, lng: number): Pin
}
interface Window {
  google: {
    maps: {
      Pin: PinConstructor
    }
  }
}
// usage in code
const pin = new window.google.maps.Pin(59.9386, 30.3141)

The same practice applies to external libraries, for example when extending Express’s req and res objects.

`noStrictGenericChecks`

Configured by default. Do not change it.

Overriding this flag can make the compiler more “lenient” with generics:

type A = <T, U>(x: T, y: U) => [T, U]
type B = <S>(x: S, y: S) => [S, S]
function f (a: A, b: B) {
  // OK
  b = a
  // this should be an error, but the compiler ignores it
  a = b
}

`Advanced`: summary

The section contains many unrelated flags. Some concern compiler strictness and could be moved to thematic sections.
allowUnreachableCode and allowUnusedLabels are linting flags and could move to Linter Checks.
noImplicitUseStrict, noStrictGenericChecks, suppressExcessPropertyErrors, and suppressImplicitAnyIndexErrors are the defaults that provide TypeScript’s built-in type safety.
You can forget about the other four flags.
noImplicitUseStrict is a variation of alwaysStrict.
noStrictGenericChecks, suppressExcessPropertyErrors, and suppressImplicitAnyIndexErrors turn off some basic syntax checks to make difficult JavaScript-to-TypeScript migrations easier.

Conclusion

To finish, here is a cheat sheet of every flag mentioned above for maximum strictness and clarity.

tsconfig-checks.json:

{
  "compilerOptions": {
    // Strict Checks
    "alwaysStrict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "strictFunctionTypes": true,
    "noImplicitThis": true,
    "strictBindCallApply": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    // Linter Checks
    "noImplicitReturns": true, // https://eslint.org/docs/rules/consistent-return 🛑
    "noFallthroughCasesInSwitch": true, // https://eslint.org/docs/rules/no-fallthrough
    "noUnusedLocals": true, // https://eslint.org/docs/rules/no-unused-vars
    "noUnusedParameters": true, // https://eslint.org/docs/rules/no-unused-vars#args
    "allowUnreachableCode": false, // https://eslint.org/docs/rules/no-unreachable 🛑
    "allowUnusedLabels": false, // https://eslint.org/docs/rules/no-unused-labels
    // Base Strict Checks
    "noImplicitUseStrict": false,
    "suppressExcessPropertyErrors": false,
    "suppressImplicitAnyIndexErrors": false,
    "noStrictGenericChecks": false,
  }
}

Why tsconfig-checks.json? In part one, we discussed using config inheritance so strictness settings do not get mixed with other options. That is exactly what we will do.

tsconfig.json:

{
  // strictness settings
  "extends": "./tsconfig-checks.json",
  "compilerOptions": {
    // all other settings
  }
}

And for a smoother development experience, so unreachable code and unused variables do not break compilation, you can do this:

tsconfig-dev.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    // disable some linting so compilation does not break
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "allowUnreachableCode": true,
    "allowUnusedLabels": true
  }
}

That is all for now. Next, I plan to dig into optimization and performance options and will be sure to share what I find. See you next time!

This article is based on my thread on the collective @jsunderhood account.

P.S. I also sometimes write about TypeScript and development on @barinbritva.

TypeScript: Sorting out tsconfig. Part 1

Barin Britva — Mon, 12 Apr 2021 10:22:42 +0000

I’m a big fan of TypeScript. Each new project I prefer to write on TS rather than native JavaScript. In this article, I will not discuss the reasons for choosing TypeScript or its advantages and disadvantages. I’d like this article to be a guide for those who want to learn how to set up tsconfig, to sort out its numerous flags and learn some useful tricks.

So, in this article I want to provide a revised and streamlined documentation summary, which I believe will be useful to those who are standing at the begging of their path to TypeScript or for those who didn't find time or energy to sort out the details and want to fill this gap.

When you’re opening official reference tsconfig you’ll see a full list of settings divided into groups. However, it doesn't allow you to understand what you should start with and which of these options are required and what can be skipped (for some time). Plus, some options are grouped by technical meaning, not logical. For example, some verification flags could be found in Strict Checks group, some in Linter Checks and others in Advanced group. It’s not always easy to understand.

All the options, just like the article itself, I divided into two groups – basic and “checks”. In the first part we'll talk about basic settings and in the second – different checks, i.e. tuning compiler strictness.

Tsconfig structure

Let’s have a look at the structure and some features of the config.

tsconfig.json has 2 parts. Some options must be specified in root and some of them in compilerOptions
tsconfig.json supports comments. Such IDE like WebStorm or Visual Studio understand this and do not highlight comments as a syntax error
tsconfig.json supports inheritance. Options can be divided according to some principle, described in different files and merged with the special directive

Here is a blank of tsconfig.json:

{
  // extends you to enrich options with other options from the specified file
  // we'll return to tsconfig-checks.json file in the next article
  "extends": "./tsconfig-checks.json",
  // project-specific options are based in config root
  "compilerOptions": {
    // all compiler related setting will be placed here
  }
}

root options are: extends, files, include, exclude, references, typeAcquisition. Of these, we will consider the first 4. Other options are based in compilerOptions.

Sometimes some options like compileOnSave and ts-node can be placed in root section. These options are not official and can be used by IDE for its needs.

Root section

`extends`

Type: string | false, default: false.

Specifies the path to the file from which to inherit options. For the most part it serves as an organizing tool. Options can be divided according to some logic so that they don’t mix. For example, move config strict settings to separate file the way it’s shown in the config draft. However, given the support of comments in tsconfig.json this can be done much easier.

{
  "compilerOptions": {
    // basic settings block

    // strict settings block
  }
}

Let’s have a look at another use-case where comments can’t be a solution. If we need to create production and development configs. This is how tsconfig-dev.json version can look:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    // redefining setting needed for dev env only
    "sourceMap": true,
    "watch": true
  }
}

In general, I recommend using extends. But don't break setting too much. This can become confusing. Due to the fact that multiple inheritance is not supported.

In case of using this option to see the final merged config version use command tsc --showConfig.

`files`

Type: string[] | false, default: false, related to include.

You can specify a list of specific files for compilation using this option.

{
  "compilerOptions": {},
  "files": [
    "core.ts",
    "app.ts"
  ]
}

This option will be useful for only small projects with several files.

`include`

Type string[], default: depends on files, related to exclude.

If option files is not set up TypeScript will use this directive to search for files to compile. If include is not declared too then its value will be set up as ["**/*"] by default. This means that the search for files will be carried out in all folders and their subfolders. This behavior is not optimal, so for performance reasons it’s best to always specify paths. There can be paths to specific files or path patterns.

{
  "compilerOptions": {},
  "include": [
    "src/**/*",
    "tests/**/*"
  ]
}

If patterns don’t include specific extensions TypeScript will look for .ts, .tsx and .d.ts files. And if allowJs flag is enabled - then .js and .jsx files also.

These formats are doing the same src, ./src, src/**/*. I prefer ./src.

Technically using include and exclude options TypeScript will create a list of all matched files and place it to files. You can check it by running tsc --showConfig command.

`exclude`

Type: string[], default: ["node_modules", "bower_components", "jspm_packages"].

This directive can be used to exclude unnecessary paths of files that was added by include directive. By default, the option is set to the paths of the npm, bower and jspm package managers, since the modules are already built in them. Besides TypeScript will ignore this folder from outDir option if it was added. This is the folder where the collected built artifacts are placed. It is logical for them to be excluded. To add your values to this option it’s necessary to restore the defaults. Because user’s values are not merging with default values. In other words, you need to manually specify the root of your package manager modules.

{
  "compilerOptions": {},
  "exclude": [
    "node_modules",
    "./src/**/*.spec.ts"
  ]
}

exclude option can’t exclude files added by using files option.

exclude option can’t exclude files that imported in other files which are not excluded.

compilerOptions section

`target`

Type: string, default: ES3, affects options lib, module.

The version of ECMAScript standard in which code will be compiled. Has a lot of choices: ES3, ES5, ES6 (same as ES2015), ES2016, ES2017, ES2018, ES2019, ES2020, ESNext. For backend apps/packages ES6 is okay if you’re using only modern versions of Node.js and ES5, to support the older versions. ES6 is supported by 97.29% browsers at the moment. So, the situation for frontend apps is the same.

`module`

Type: string, default: depends on target, affects the option moduleResolution.

A modular system that your compiled application will use. You can choose: None, CommonJS, AMD, System, UMD, ES6, ES2015, ES2020 or ESNext. For backend apps/packages ES6 or CommonJS is suitable depending on Node.js version you want to support. For frontend apps ES6 is also suitable. And for support of older browsers and isomorphic applications, UMD is definitely worth choosing.

If your situation is not so easy or you want to know all the intricacies of modular systems, then you need to learn the full documentation.

`moduleResolution`

Type: string, default: depends on module.

A strategy will be used for modules import. Includes only two options: node and classic. But classic won't be using in 99% of cases cause it’s legacy. However, I specifically mentioned this flag as it changes depending on the previous flag. Changing value of module option moduleResolution mode can be switched to classic and the console will start to display error messages on the lines with imports.

To avoid this situation, I recommend that you always explicitly specify the node value for this flag.

`lib`

Type: string[], default: depends on target.

TypeScript includes typings (*.d.ts-files) to support the corresponding specifications depending on which target is set in the config. For example, if your target is set up to ES6 TypeScript will include support of array.find and other options that are in this standard. But when target is set up to ES5 find method can’t be used because it’s not available in this JavaScript version. Polyfills can be added. However, in order for TypeScript to understand that this functionality can now be used, it is necessary to include the related typings in the lib section. Also, you can connect the entire ES2015 standard or its part ES2015.Core (only find, findIndex etc. methods).

Sure it’s better to include typings only for the functionality for which polyfills were previously installed.

For --target ES5 will be lined up: DOM, ES5, ScriptHost
For --target ES6: DOM, ES6, DOM.Iterable, ScriptHost

The defaults are reset at the time you’re adding anything to lib. It’s necessary to manually add what you need, for example DOM:

{
  "compilerOptions": {
    "target": "ES5",
    "lib": [
      "DOM",
      "ES2015.Core"
    ]
  }
}

`outDir`

Type: string, default: equals a root directory.

The final folder where the collected artifacts will be placed. There are: .js, .d.ts, and .js.map files. If no value was set for this option, then all the above files will be copying the structure of the source files at the root of your project. In this case it’ll create difficulties with deleting previous builds and describing .gitignore files. As a result, the code base will look like a dump. My advice is to put all artifacts in one folder which may be easily deleted or ignored by the version control system.

If you leave outDir option empty:

├── module
│   └── core.js
│   └── core.ts
├── index.js
└── index.ts

If you specify outDir:

├── dist
│   └── module
│   |   └── core.js
│   └── index.js
├── module
│   └── core.ts
└── index.ts

`outFile`

Type: string, default: none.

According to the description this option allows to unite all files into one. It seems that bundlers like webpack are no longer needed... However, this option works only if None, System, or AMD value set up for module. Much to our regret, the option won't work with CommonJS or ES6 modules. Therefore, you probably won't need to use outFile. Since the option looks so attractive, but does not work as expected, I decided to warn you about this giant pitfall.

`allowSyntheticDefaultImports`

Type: boolean, default: depends on module or esModuleInterop.

If one of the libraries doesn't have default import such loaders as ts-loader or babel-loader will create it automatically. But d.ts-files files of this library don't know anything about it. This flag allows compiler to write like this:

// instead of this import
import * as React from 'react';
// you can use this
import React from 'react';

It's a default option when flag esModuleInterop is enabled or module === "system".

`esModuleInterop`

Type: boolean, default: false.

By adding a boilerplate to the output code, it allows you to import CommonJS packages as ES6.

// moment library exporting only like CommonJS
// trying to import it as ES6
import Moment from 'moment';

// without esModuleInterop flag the result is undefined
console.log(Moment);

// with esModuleInterop flag result is [object Object]
console.log(Moment);

This flag by dependency activates allowSyntheticDefaultImports. Together they help to get rid of lots of different imports and write it uniformly across the project.

`alwaysStrict`

Type: boolean, default: depends on strict.

Compiler will parse the code in strict mode and add “use strict” to output files.

false by default but if flag strict enabled then true.

`downlevelIteration`

Type: boolean, default: false.

ES6 specification added new syntax for iteration: cycle for / of, array spread, arguments spread. If the project code is compiled to ES5 then construction with cycle for / of will be converted to common for:

// es6 code
const str = 'Hello!';
for (const s of str) {
  console.log(s);
}

// es5 code without downlevelIteration
var str = "Hello!";
for (var _i = 0, str_1 = str; _i < str_1.length; _i++) {
  var s = str_1[_i];
  console.log(s);
}

But some symbols like emoji are encoded with two characters. It means that such a transformation will not work as expected in some places. downlevelIteration flag generates more verbose and more "correct", but less productive code. This code is huge so I won't take up space on the screen. You can find an example here - playground - and choose target -> es5, downlevelIteration -> true in settings.

The browser must have an implementation of Symbol.iterator to make this flag work. Otherwise, you'll need to set up polyfill.

`forceConsistentCasingInFileNames`

Type: boolean, default: false.

Enables case-sensitive mode for files import. Thereby even in case-insensitive file systems trying to make import FileManager from './FileManager.ts' will fail if the file is actually named fileManager.ts. It doesn't hurt to play it safe. TypeScript is all about strictness.

compilerOptions section options which are not needed in every project

`declaration`

Type: boolean, default: false.

By enabling this flag, in addition to JavaScript files, annotation files known as d.ts files or typings will be generated for them.
Due to typings it becomes possible to define types for already compiled js files. Other words code is compiling to js and types to d.ts-files. This can be useful if you're publishing your package to npm. All developers can use this library whether they're using native JavaScript or TypeScript.

`declarationDir`

Type: string, default: none, related to declaration.

Typings are generated next to js-files as a default. Using this option you can redirect all d.ts files to a separate folder.

`emitDeclarationOnly`

Type: boolean, default: false, related to declaration.

If for some reason you only need the d.ts files, then enabling this flag will prevent the generation of js files.

`allowJs`

Type: boolean, default: false.

This flag will help you to port your JavaScript project to TypeScript. By enabling allowJs flag you'll make TypeScript compiler process not only ts but also js files. There is no need to migrate the whole project before continuing the development. You can do it file by file changing their extensions and adding types to them. And the new functionality can be written directly in TypeScript.

`checkJs`

Type: boolean, default: false, related to allowJs.

TypeScript will check for errors not in ts but in js files also. In addition to the built-in typings for JavaScript language constructs, the TS compiler can also use jsDoc to parse files. I prefer not to use this flag but to put the code in order when I add types to it. However, if your project has good jsDoc code coverage, it's worth giving it a try.

Since version 4.1 when checkJs is enabled, the allowJs flag is automatically enabled.

`experimentalDecorators` and `emitDecoratorMetadata`

Type: boolean, default: false.

Decorator – is a common OOP pattern. It’s possible to implement it using classical approach by writing wrappers. But using the flags mentioned above, you can enable experimental decorator syntax. This syntax allows you to decorate classes, their methods and properties, access modifiers and function arguments using simple “at (@)” syntax, which is widespread in many programming languages.

The experimentalDecorators flag just activates the syntax, and emitDecoratorMetadata provides decorators with additional metadata at runtime, with which you can significantly expand the scope of this feature.

To make emitDecoratorMetadata work you need to add reflect-metadata library.

`resolveJsonModule`

Type: boolean, default: false.

Flag allows to enable ability to import *.json files. No additional installation is required.

// .json extension must be specified
import config from './config.json'

`jsx`

Type: string, default: none.

If the project uses React, you need to enable jsx support. In most cases react or react-native option will be enough. It is also possible to leave the jsx-code untouched with the preserve option or use the custom converters react-jsx and react-jsxdev.

Wrapping up the 1st part

In this article I wrote about the most important flags and options that can be useful in the vast majority of projects. In the next part I'll talk about compiler strict settings. I will add a link after publishing.

Choosing authentication method for a project

Barin Britva — Wed, 03 Mar 2021 15:08:58 +0000

(From my Medium - Sep 29, 2020)

It’s been a little over a year since I wrote my previous post on how to take the first steps towards a startup. During this time, I managed to implement one project, which could not be launched due to COVID-19. I am soon planning to write a separate post about this project and the technical experiments that I made while working on it. Besides, I was starting another idea, which is now put on hold, and also several other ideas have appeared that one can start to implement. In fact, different ideas often come to my mind — small and not very. Probably, in the near future my main task will be to learn to think more “businesslike”. Because now all my ideas are just some things that are interesting to me either as a potential user or as a developer. That’s not the point, though.

The main thing that I have realized during all this time is that if there are so many ideas, then one of them can take off. But for that I need to learn to launch project after project very quickly. Sometimes I think: what is the problem, really? I have a lot of experience in the field of development, my own set of frameworks and tools that I feel comfortable working with. And now, in my thoughts, I have already gone full speed and implemented all the ideas that are written in my notebook. I almost got down to work for real, opened the IDE and then … just froze for a few seconds and then all the enthusiasm was gone. Guess what I was thinking? Yes, that’s right — authentication! In 90% of cases, the project requires auth. And it became a stumbling block for me. This routine issue precedes all the fascinating work that attracted me so much when I was thinking about working on a project.

Of course, you can implement the dev version of auth or even stub, and then write the real implementation. You can pull out the code and the database scheme from the previous project, then adjust it to the current realities and delete all the extra pieces. Which often seems more costly to me than writing from scratch. It is also possible to use third-party services, such as Auth0, which at first glance may seem extremely attractive. There is no need to develop authentication yourself, there is auth by login and password, as well as through social media.

A lot of social media connector at Auth0

However, I always have doubts about using external services, especially when it comes to such a critical part of the application as authentication. Auth0 offers 7,000 free users and unlimited logins. It’s great. Perhaps the application will not have so many users and it will be fine for a pilot run. But what if the number of users of the application exceeds this number, but the application still does not bring money. And most likely by that time you’ll be already paying for hosting and other services like mailing lists, monitoring systems, analytics. What if the same abstract Auth0 does not have the support of the social network you need, or you need to add some kind of business logic to the authentication process? In other words, such services can provide a significant speed boost at the start and provide a vendor lock-in in the future.

To sum it up, I have accumulated a lot of thoughts about different auth methods, their pros and cons. Therefore, I decided to organize all this in the article below and share my experience and advice. So, let’s get started.

Classic authentication — login + password

Due to the fact that this is the oldest and most proven method, it is the most common. That’s right — you enter the username and the password — and here you go. Nowadays, you don’t have to think about how to pick a good salt to protect your password with double processing it with the md5 function to get a hash (shoutout to PHP). I believe, any language already has a 100 per cent proven and safe way to do it. There are still some nuances, though.

From the user side:

Users often come up with passwords that they are sure they will certainly not forget. But in the end, they constantly mess around with annoying forms of password recovery. And in case your resource has not proven its need for the user, they can quit this business halfway through.
So as not to forget passwords, users often have one for all occasions. However, most likely users don’t trust your resource at the initial stage. And the user will think ten times before risking the key to all his doors. With a high degree of probability, such a user will close an untrusted resource.
For obvious reasons resource developers frequently set up password strength rules (we’ll talk about it below). In case the user from paragraph 2 decided to set his password, it so often happens that security rules suggest adding a couple special characters or numbers to this password. In such cases some types of app users will close your app immediately (I was in this group of users too). But if a user decides to upgrade his password with a couple of new symbols, he risks falling into the group of users from paragraph 1.

A service takes care about your security by checking your password strength

A user might not remember if he has registered on this portal before or not. What to choose — registration or authentication? I can’t sign in because I don’t have an account or because of the wrong password? Screw that, I’ll just reset the password. Okay there is no link to reset my password, but … why? Is it because I wasn’t registered, or mail sending is taking too long or there are problems on service side?
A registration form often has custom fields on top of credential fields: name, sex, address etc. Having seen this a user, not being 100% sure they need this particular service, might just run away. Ideally a registration form shouldn’t have any extra fields. Any extra info can be requested when the time comes. For example, in e-commerce store you’d better not ask a customer for their address during the initial registration — he may never make an order — but wait right till checkout instead. For sure, there can be some exceptions. In case you need to show what services are available based on the user’s address. Anyway, if you need to have some extra data, I’d recommend to always do it in the second step. We first create an account that contains only credentials and then fill in the profile with other important info. Thus, we’ll decrease the probability of a user disappearing in step one. If however he’ll runaway in step two, we still have his email. Potentially we can bring such a user back. The main thing is not to be too aggressive or obsessive doing that.
User can face the biggest internet-spawned evil — captcha. This is a big separate story that we won’t dwell on here. Just try to make a list of your 10 most hateful things (about registration/authentication). I’m sure captcha will rank high on this chart.

On the dev side it’s simple — one has to do a huge amount of work.

Implementation of login and password input, their processing, output of clear error messages in the program interface. Saving the session in cookies or issuing a JWT token.
Cookies for storage is a fairly old mechanism that is gradually becoming a thing of the past and is being replaced by JWT tokens. This is also a large separate topic for discussion. Let me just say that JWT is very good. But it takes more time and effort to implement authentication through tokens, as well as understanding of how access tokens and refresh tokens work, what they are used for and so on.
You need to think about security of users and the service itself. Therefore, you’d better integrate (or write your own) solution to check the strength of the created passwords, and also correctly convey this information to the user through the interface. For greater security, perhaps you might notify the user that it is time for him to change the password, say, in 3 months? Or even demand a new password from him immediately after authentication by means of the expired password? Well, no — it’s too much!
To increase security, of course, you should implement captcha. At least display it after several unsuccessful authentication attempts (which in itself is additional work). What should you take? Google reCAPTCHA with its traffic lights and bridges or invisible mode that trusts you simply because you are logged in to Google services. Or curvy, hard-to-read self-made characters, which are considered incorrect even if everything is entered correctly, at the sight of which the user will close the tab or application? You need to think. Perhaps I will leave this question unanswered.

A user is trying to pass reCAPTCHA

The classic form of authentication/registration is rich in various flows. Separation of authentication and registration, functionality “forgot password”, “forgot login”, confirmation of the account by clicking the link received by email. All these things put a load on both interface development and the logic. It is necessary to add letter sending. But what should I put in the letter? A link to the new password form? A ready-made temporary password that will have to be changed in your personal account? I would choose the first option from a developer’s point of view since it is safer. And the second from the user’s point of view — it’s faster this way. Either way, these are the things you have to worry about and ultimately implement.

One-time password authentication (arrives by email or SMS)

In my opinion, in comparison with the previous method, this option can be called ideal for the user. You enter your login, receive an email or a text with an access code. This solves almost all the difficulties a user encounters when working with classic authentication. And for a developer, in a sense, this method is easier to implement. At least, the developer does not need to think about the complexity of the password and the flow becomes very simple — due to the lack of separation of registration and authentication and the password recovery function. For me, these points are extremely significant and outweigh the concerns that this method adds. However, these conveniences have their own price… So, the cons.

From the user side:

If the user is not actively using email, then it is possible that he is not signed in in his email client. And if email does not play a role in his life at all, then there is a possibility that it will be so difficult for the user to remember his mail credential that he will not even try. A simpler case is also possible. For example, a user works with mail only on a computer, and tries to access your service from a phone. There is no computer at hand … Well, you understand. To be honest, I have no idea how both of these options are possible in real life, especially the first one. But all I want to say here is that this method essentially makes your service dependent on another service. Of course, you can prompt the user to log in with a phone number. The phone is more often at hand. However, the user will leave his phone number to an untrusted service only as a last resort. In general, I recommend using phone logins only if it makes sense. For example, you have a courier delivery service, and the courier needs your number for quick communication. Otherwise, both you and your users will suffer. So, offering the choice of either email or phone — yup, but forcing the phone option on them — big no-no.
For some reason, email or SMS may be delayed and, in some cases, delayed significantly, and sometimes not come at all. Of course, if everything works stably on the part of your service and mail providers, there should be no problems.

One-time password is sent by email

As for the developer:

To prevent emails with access codes from getting into spam, it is necessary to integrate with trusted message sending providers, such as: Mailchimp, Mailgun. If authentication is only done by email, then you have one provider. If authentication is done by email and phone, then you already have two. If you want to insure against a failure, then each of them should have fallback services, that is, there are already 4 integrations.
Partial inability to be responsible for the stability of your application due to the dependence of the critical part of the system (in the form of authentication) from third parties. Of course, any service is this way or another not a standalone solution and depends on something. But there are things that cannot be passed on to third parties, such as Internet access or hosting. And there are dependencies that you can avoid and reduce the likelihood of system failure. Especially when it comes to not the secondary functions of the service, but the primary ones.
Integration and guaranteeing stability are not all of your problems. The main problem here is the price. Whereas everything is more or less obvious with sending emails — there is a mailgun, which will cost $ 0.80 per 1000 messages, it is noticeably worse with sending text messages. With an average price of $ 0.05, you will have to pay $ 50 for the same amount! Which is completely overwhelming for launching a startup that is not yet generating income. If you know cheap or maybe even free services for sending email or SMS, please write in the comments.
To save money, you will have to add captcha before sending the message

Two-factor and mixed authentication

If the user does not exist, authentication is performed using a one-time password. Further authentications are carried out in the same way. After the user has created a password, entering a one-time code is done as the second step if additional security is needed or this step is omitted if simplicity is required.

This method can be attractive in some cases, provided that you are absolutely certain that you need to have standard authentication via login and password. Let’s say, your application, logically speaking, cannot function at all without the user creating an account. But it would be illogical to load the user with unnecessary steps and thereby scare him away. You allow him to log in with a one-time password, thus creating a “draft” account — prospect (a marketing term describing a potential customer). By draft, I mean an incomplete account with which you can view resources, but you cannot perform some operations, such as ordering services or goods, posting articles or other materials, etc.

As soon as the user reaches the step that requires creation of a full-fledged account, the system will ask for a password. Thus, we did not lose potential users ahead of time and delayed the user’s torments as much as possible. As a result, we got a full-fledged, secure account, which is important if the application allows us to carry out financial transactions. If security is not so critical, you can allow the user to enable and disable two-factor authentication.

Two factor authentication adds extra security to your account

Since this method contains the functionality of the previous two approaches, it incorporates all the pros and cons of both.

Social media authentication

And, of course, authentication using our favorite social media. The method is extremely interesting and attractive. But, unfortunately, with its own serious shortcomings. On the positive side — we completely save the user from almost all the problems listed earlier! If a user has an active account on a social media, he can easily use our resource and any other resources that support authentication through social media. As a bonus, the user gets the opportunity to manage their sessions through a centralized location. Has your phone or computer been stolen? Go to your social media account and close sessions in all related applications — your accounts are under reliable protection. Also, signing through social media eliminates the need to verify the account — social media itself does this. And this approach frees the developer from a huge amount of decision-making and work, which is worth a lot!

Rich diversity of social connectors allows you to find the exact connector you need

However, for some reason, applications that only use social media authentication represent tiny minority. It’s time to look at the flaws.

For the user:

What if the user does not use any social media? Yes, I have met people a couple of times claiming that they are not on any network. I am sure that in the modern world, if a person uses the Internet in principle, then most likely he will have some kind of account. At least a Google or Apple account from his smartphone. Some more people who avoid social media have nevertheless fake accounts for different purposes. But the main idea here is that in a rare case, you can lose a potential user due to the lack of an alternative authentication method.
Consider a completely opposite situation. I am an imaginary user who replaced real life with online one on a social media. I have all the social media that your application offers me for authentication. I can’t remember if I logged in to this service earlier or I just don’t remember what I used — Facebook, Instagram, Twitter… I clicked the wrong icon and got an empty account. Also, all applications implement sign in through a different set of networks. I would be happy to use everywhere, say, Twitter. This option is not always available, though. It would be convenient if the authentication method that was last used by the user was highlighted in the application interface. You can store this information in cookies or local storage. However, if you use the service from another device or even a browser, magic won’t work. So, this is only a partial solution to the problem. For me personally, this is the number one reason why, as a user, I rarely make a choice in favor of authentication via social media networks. I have not been able to work out an algorithm on how to choose a social media to sign in. Therefore, I usually just register with the service directly. Moreover, I have 1Password. But more on that at the end of the article.
And what kind of service is it, exactly? Can I trust it to access my imaginary Facebook account? Will the service abuse my trust and use my data for its own hidden purposes? There are several problems with understanding the “rules of the game.” First, a list of data that will be transferred from the social network, appears only after you click on its icon and the authentication window in an external resource has opened. Secondly, a correctly configured scope on the part of developers plays a huge role. Scope is a list of privileges that the application will ask for from a social network. Sometimes applications ask for too many privileges and it is not always clear whether this is really necessary. Maybe the developer just requested the full scope so as not to deal with this, maybe he even wanted to return to the question by the time of the first release but forgot. Or maybe the application has its own plan for user data. In any case, this looks just as suspicious as an application on the phone that requests access to the microphone, while it does not have audio/video recording functions or support for voice commands. Therefore, it seems to me that it would be nice to familiarize the user with what kind of data you intend to use and how. This is especially important if your application contains functionality that the user does not know about. Just one example of the top of my head: we use write permissions not to post ads on your wall, but to save photos from the application to your photo album.

App requests the scope

Another small point about safety, but from a different angle. In the most innocent case, a service can display in the user profile a link to the social network through which he signed in. Which can be undesirable for a number of reasons. From a simple “I don’t want to” to a desire to separate different areas of your life.
Also, if the user is far from IT, it may not be clear to them what auth is and how it works. I am sure that there are still users who, seeing the offer to enter their email and password when signing in the application, mistakenly believe that it is actually their email account password that they are asked to input right now. And given the fact that users often have one password for all occasions… So, not every user understands that the password is entered on the side of the imaginary Facebook, and not in the application for which authentication is required. Therefore, not everyone wants to risk their only password.

Your app redirects user to the chosen social network to complete the authentication on their side

For the developer:

You’ll have to create a developer account for each social media to get tokens and API keys. That’s not easy nowadays. For instance, to obtain Twitter API access it’s required to write a detailed explanation how your application intends to use the provided data. All app creation requests will be moderated manually by real people. In case a moderator gets any doubts, you’ll receive an email with extra questions. Each social media may have their own policies and requirements. That’s means to implement authentication through the number of social media you will have to spend time and make some effort.
If you are not going to use ready solutions like Passport.js or there are no similar packages for the platform you use to develop your app, you will have to read a lot of different documentation and integrate all those API’s in manual mode.
Different social media provide different user data. For example, some social media won’t give you a user email, which is necessary for your app. That’s why you can’t avoid implementing the second step to collect missing data.

Conclusion

Ugh, well, I am done with all the methods, pros and cons that I have come across in my experience. I told you everything I knew. Finally, of course, I would like to share my opinion on when to choose which method. At the end of the day, all these thoughts came to my mind in the process of thinking about how to quickly do auth in my future projects.

It seems to me that in the balance between usability and speed/ease of implementation, one-time password authentication wins. If you are developing MVP or PoC, you can even postpone integrations with mailing services until you start attracting real users. That is, at the stage of development and testing in a closed circle and demonstrating the application to investors, you can get by sending login codes through a standard function or a function from some third-party libraries, which I am sure exist in every programming language.

Of course, authentication only through social media can be a great option too. For example, if you know your target audience perfectly. So, Tinder, when it was just launched and for a long time after, had authentication only through Facebook. Even photos could only be uploaded to a profile from Facebook albums. A real startup approach! If you are making an app for developers, it will most likely be sufficient to support the login via GitHub. But if everything is not so obvious, then you will have to implement user authentication sign in via the top 5–7 social media networks. Even at the stage of closed beta testing or showing it to potential partners.

If you need a wide range of authentication methods at the very start and are not afraid to get a vendor lock-in, then things like Auth0 and Firebase Authentication are most likely exactly what you need.

I can only show you the doors, but you’re the one who decides which one to choose

What do you think about it? What problems do you see when creating auth for a project? Perhaps you know ways to easily solve all these problems, for example, an analogue of oAuth, only open source. With any thoughts on this topic, I am glad to welcome you in the comments.

P.S.: So, I mentioned 1Password. This is by no means an advertisement. It’s just that I’ve been using it for over a year now and highly recommend it to anyone who wants to end the password confusion while staying safe. I create different passwords using the built-in password generator and 1Password remembers everything for me. All I have to do is show my face for Windows Hello to allow 1Password to fill out the login form. And on a smartphone, I use a fingerprint. It’s incredibly convenient! If you don’t have biometrics on your device, then everything is the same for you — you only need to remember one password, from 1Password itself.

From the idea to the side project

Barin Britva — Wed, 03 Mar 2021 14:40:54 +0000

(From my Medium - Jul 4, 2019)

A few times in my life I had ideas of projects which didn’t want to leave my head either during at day nor at night. I haven’t finished any of them yet, but I’ve gotten a lot of valuable experience that I’m planning to use in the near future. Here are several things I have noticed.

I guess it’s not a secret to anybody that any project must start from MVP. To do that you should imagine an application of your dream and then move all unnecessary features to the backlog. You can also compose a feature roadmap to specify iterations. Working on one of my projects I almost did it this way, but I ran into over-management — I started the project in Jira, created some releases, stories, sprints, etc. It was a huge mistake. I would recommend using a simple text file for a start. And the main point here is — you mustn’t be seduced to add any new features to your MVP, even if this feature is very small.

For instance, a simple desire to add nice small avatars for users may become a hard, long story about including third-party libraries, static files storing, validating of uploaded files and after all of that, you have to create crop image functionality. All the things that maybe not done mustn’t be done.

The second important point is the following: even if you managed to design minimum functionality and created a boilerplate of application it isn’t a victory yet. The situation when your free time for the project is not enough will come soon. You would like to relax sometimes at weekends but allocated two hours on a weekday may be wasted on ridiculous bug searching instead of development. That’s why it makes sense to take a break for a few months and work on your project in full-time mode. By the way, it’s a good possibility to check how powerful your faith in your own idea is. For example, my faith wasn’t strong enough in the last project.

And another paramount thing — the process can drag for a long time just because you may not know what to do next after the technical part of the product is finished. How to run the project in production, what are the markers of successful and unsuccessful launch, where I can get the investments? To get some orientation in the business part of products and get the basic knowledge about it you can go to a so-called “pre-accelerator”. There you will be able to meet with a curator who will help you with all these questions.

What’s next? I don’t know yet. But as soon I’ll know I will tell you.

Good luck with your ideas! 😉

DEV Community: Barin Britva

TypeScript: Sorting out tsconfig. Part 2

TypeScript: Sorting out tsconfig. Part 2

The Strict Checks group

alwaysStrict

strict

noImplicitAny

strictNullChecks

strictPropertyInitialization

strictFunctionTypes

noImplicitThis

strictBindCallApply

Strict Checks: summary

The Linter Checks group

noPropertyAccessFromIndexSignature

noUncheckedIndexedAccess

noImplicitReturns

noFallthroughCasesInSwitch

noUnusedLocals

noUnusedParameters

Linter Checks: summary

The Advanced group

allowUnreachableCode

allowUnusedLabels

noImplicitUseStrict

suppressExcessPropertyErrors

suppressImplicitAnyIndexErrors

noStrictGenericChecks

Advanced: summary

Conclusion

TypeScript: Sorting out tsconfig. Part 1

Tsconfig structure

Root section

extends

files

include

exclude

compilerOptions section

target

module

moduleResolution

lib

outDir

outFile

allowSyntheticDefaultImports

esModuleInterop

alwaysStrict

downlevelIteration

forceConsistentCasingInFileNames

compilerOptions section options which are not needed in every project

declaration

declarationDir

emitDeclarationOnly

allowJs

checkJs

experimentalDecorators and emitDecoratorMetadata

resolveJsonModule

jsx

Wrapping up the 1st part

Choosing authentication method for a project

Classic authentication — login + password

One-time password authentication (arrives by email or SMS)

Two-factor and mixed authentication

Social media authentication

Conclusion

From the idea to the side project

TypeScript: Sorting out `tsconfig`. Part 2

The `Strict Checks` group

`alwaysStrict`

`strict`

`noImplicitAny`

`strictNullChecks`

`strictPropertyInitialization`

`strictFunctionTypes`

`noImplicitThis`

`strictBindCallApply`

`Strict Checks`: summary

The `Linter Checks` group

`noPropertyAccessFromIndexSignature`

`noUncheckedIndexedAccess`

`noImplicitReturns`

`noFallthroughCasesInSwitch`

`noUnusedLocals`

`noUnusedParameters`

`Linter Checks`: summary

The `Advanced` group

`allowUnreachableCode`

`allowUnusedLabels`

`noImplicitUseStrict`

`suppressExcessPropertyErrors`

`suppressImplicitAnyIndexErrors`

`noStrictGenericChecks`

`Advanced`: summary

`extends`

`files`

`include`

`exclude`

`target`

`module`

`moduleResolution`

`lib`

`outDir`

`outFile`

`allowSyntheticDefaultImports`

`esModuleInterop`

`alwaysStrict`

`downlevelIteration`

`forceConsistentCasingInFileNames`

`declaration`

`declarationDir`

`emitDeclarationOnly`

`allowJs`

`checkJs`

`experimentalDecorators` and `emitDecoratorMetadata`

`resolveJsonModule`

`jsx`