DEV Community: Acid Coder

Stop using Eslint and Prettier, use Biomejs instead! End Bike Shedding, End Endless Configurations!

Acid Coder — Wed, 18 Jun 2025 02:47:33 +0000

Eslint and Prettier are frustrating to configure, they also run slowly

Introduce Biomejs, the next generation linter and formatter, written in Rust!

Setup Biomejs in vscode in mere 4 simple steps!

install Biomejs npm i -D @biomejs/biome
install Biomejs vscode extension
(optional)create biome.jsonc in root folder

{
    "javascript": {
        "formatter": {
            "quoteStyle": "single",
            "semicolons": "asNeeded"
        }
    }
}

This is my favorite configuration, simple and clean, I want to reduce noise as much as possible.

You are free to modify it, the js rules work with typescript out of the box.

create a .vscode/settings.json file in root folder

{
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "biomejs.biome",
    "[typescript]": {
        "editor.defaultFormatter": "biomejs.biome"
    },
    "[jsonc]": {
        "editor.defaultFormatter": "biomejs.biome"
    },
    "[typescriptreact]": {
        "editor.defaultFormatter": "biomejs.biome"
    }
}

and it is done, enjoy!

TS-Hajime: Effortlessly Bootstrap TypeScript NPM Libraries

Acid Coder — Sun, 13 Oct 2024 14:24:45 +0000

I made a library that can easily bootstrap your TypeScript library with better DX tools. It focuses on minimal setup and visual clarity.

GitHub

Features:

Sensible defaults.
Built with DX tools like pkgroll, tsx, tsup, vitest, and clieye.
Preconfigured tsconfig, eslint, vitest, prettier, package.json, and .gitignore files.
Ready-to-use GitHub Actions, pre-commit hooks, and npm scripts.
Examples and tests included for both library code and npx commands.
Write npx commands directly in TypeScript.
Outputs both ESM and CJS modules.
(VSCode)Pre-configured with file nesting, auto-prettify on save, and a specified TypeScript TSDK path.
Exposed configurations allow for complete customization to fit your needs.

To get started:

Run the command below to bootstrap your project:

   npx ts-hajime your-app-name-here

Here’s what your project structure will look like:

Replace all occurrences of my-app with your app’s name and my-description with a description.

Key commands:

Build: npm run build
Test: npm test
Lint & Fix: npm run lint
Type Check: npm run tsc (Note: Type checking is automatically done in GitHub Actions as part of the build step with pkgroll.)
Try npx Command Locally: npm run npx something (Modify the npx script in package.json to suit your project requirements.)

Remember to star it if you like it!

Typescript Flatten Object Type

Acid Coder — Thu, 29 Jun 2023 18:54:03 +0000

type ToPaths<T, P extends string = ''> = T extends Record<number, unknown>
    ? {
        [K in keyof T]: ToPaths<T[K], `${P}${K & string}.`>
    }[keyof T]
    : { path: P extends `${infer P}.` ? P : never; type: T }

type FromPaths<T extends { path: string; type: unknown }> = {
    [P in T['path']]: Extract<T, { path: P }>['type']
}

type A = FromPaths<ToPaths<{
//  ^?
    a: 1,
    b: {
        c: 2,
        d: Record<string, {
            e: 3,
            f: 4,
        }>,
        g: 5,
    },
    h: {
        i: {
            j: 6,
        },
    },
}>>

playground

Typescript Nominal Type: The Right Way

Acid Coder — Wed, 28 Jun 2023 19:56:45 +0000

In case you don't know what RighFminal typing

Typescript is a structural typing language, but it is possible to mimic the behavior of nominal typing language, very closely.

We start with the easiest method:

type AB = { a:number, b:number, x:never}
type BA = { a:number, b:number, y:never}

const ab:AB = {a:1, b:2}
const ba:BA = ab // error !!

playground

It works

BUT THIS IS NOT GOOD ENOUGH !!

Today we are going to learn how to create a proper nominal type in Typescript

Let us review why the first method is not good enough.

First, it uses type assertion. Avoid type assertion if possible, personally I only assert type when I am creating wrappers.

Second, users can access the extra property: brand via static typing. In this case, our brand is ab.x and ba.y.

As a craftsman, we don't want that to happen

Solution

declare class AB_Class { 
    protected x?:never
}

declare class BA_Class { 
    protected x?:never
}

interface AB extends AB_Class{
    a:number, b:number
}

interface BA extends BA_Class{
    a:number, b:number
}

const ab:AB = {a:1, b:2} 
const ba:BA = ab // error !!

playground

The key is to use class and declare optional protected brands with never as type.

The brands name don't have to be the same name, you can assign different names.

no type assertion
users cannot access brand

now, you may ask, why protected, why not private?

This is because, take this example

declare class AB_Class { 
    private x?:never
}

after tsc compilation, the output is

declare class AB_Class { 
    private x?
}

do you notice the difference?

Typescript strips away the type of private and fails type assertion

so please stick with protected

Typescript Type Level Custom Error Message For Utility Types

Acid Coder — Wed, 28 Jun 2023 15:45:34 +0000

In the previous article, we have learned how to create custom type level error message for our function

In this article, we are going to learn how to create custom type level error message for...type itself!

Now imagine we want to create a type converter that convert true and false to 1 and 2 respectively

We want to convert either true or false, but we don't want to convert both

type A <T extends true | false, U = T> = T extends true ? 1 : 2

type X = A<boolean> // no error, but we dont want this
//   ^?
type Y = A<true> 
//   ^?
type Z = A<false> 
//   ^?

const x1:X = 1
const x2:X = 2
const y:Y = 1
const z:Z = 2

playground

No error or what so ever

Normally the solution is:

type A <T extends true|false, U = T> = boolean extends T ? "You cannot convert type `boolean` !": T extends true ? 1 : 2

type X = A<boolean> // no error, but we dont want this
//   ^?
type Y = A<true> 
//   ^?
type Z = A<false> 
//   ^?

const x1:X = 1 // error
const x2:X = 2 // error
const y:Y = 1
const z:Z = 2

playground

nice, we have the error, the user know what is wrong!

but we can do better, we can let the user know something is wrong earlier

type A <T extends [U] extends [boolean] ? (boolean extends U ? "error: cannot use `boolean`, please use `true` or `false` instead" : U) : "error: expected a boolean", U = T> = T extends true ? 1 : 2

type X = A<boolean> // error with custom error message!
//   ^?
type Y = A<true> 
//   ^?
type Z = A<false> 
//   ^?

const x1:X = 1 // no error, because error is lifted 
const x2:X = 2 // no error, because error is lifted 
const y:Y = 1
const z:Z = 2

playground

If you are creating utility type library, this will further enhance your users dev experience

It warns your users when they use your type improperly
The error acts as quick documentation that teaches your users how to use the type correctly

Typescript Type Level Custom Error Message, Move Runtime Error to Compile time Error!

Acid Coder — Mon, 26 Jun 2023 12:18:06 +0000

Do you want a more descriptive error message rather than usual type A cannot assign to type B?

for example, take this function:

function (a, b, c) => {}

Requirement:

all arguments are number
if a is 1, b cannot be 2
if b is 2, c cannot be 3
if c is 3, a cannot be 1

Solutions:

declare function ABC<A extends number, B extends number, C extends number>(
    a: 1 extends 1 ? C extends 3 ? A extends 1 ? "'a' cannot be 1 if 'c' is 3" : A : A : A,
    b: 1 extends 1 ? A extends 1 ? B extends 2 ? "'b' cannot be 2 if 'a' is 1" : B : B : B,
    c: 1 extends 1 ? B extends 2 ? C extends 3 ? "'c' cannot be 3 if 'b' is 2" : C : C : C
    ): void


ABC(1,2,4) // error at `b`

ABC(4,2,3) // error at `c`

ABC(1,4,3) // error at `a`

playground

How Does It Works?

We use a simple example to demonstrate, where the requirement is the argument cannot be 1.

declare function ABC<A extends number>(
    a: A extends 1? "a cannot be 1": A
    ): void


ABC(1) // error
ABC(2)

playground

The formula is

condition ? {{type checking}} : Naked Generic Type Parameter

condition ? Naked Generic Type Parameter : {{type checking}}

As long as you place the Naked Generic Type Parameter in either true case or false case, Typescript can infer the type from the argument where the conditional type is.

It works regardless of a case is reachable or not:

declare function abc<A>(
    a: A extends never ? A: A & 2
    ): void

abc(1) // error
abc(2)

playground

But it still obey the flow of condition, so this will not work:

declare function ABC<A extends number>(
    a: A extends 1?  A :"a cannot be 1"
    ): void

ABC(1) // no error (wrong!)
ABC(2) // error (wrong!)

playground

Object Literal Type

What if we want to restrict the type of object property?

Take this example where the requirement is property b cannot be 2 if property a is 1

declare function ABC<T extends { a: number, b: number }>(
    a: { a: number, b: T['a'] extends 1 ? T['b'] extends 2 ? "'b' cannot be 2 if 'a' is 1" : T : T }
): void

ABC({a:1,b:1}) 
ABC({a:1,b:2}) 
ABC({a:1,b:3}) 

// bad, error at all cases

It does not work and the logic does not make sense.

solution:

declare function ABC<const T extends { a: number, b: number }>(
    a: [T] extends [T] ? { a: number, b: T['a'] extends 1 ? T['b'] extends 2 ? "'b' cannot be 2 if 'a' is 1" : T['b'] : T['b'] } : T
): void

ABC({ a: 1, b: 1 }) // ok
ABC({ a: 1, b: 2 }) // error!
ABC({ a: 1, b: 3 }) // ok

playground

formula:

[Naked Generic Type Parameter] extends [Naked Generic Type Parameter] 
? {{type checking }} : Naked Generic Type Parameter

Do note that below will fail:

Naked Generic Type Parameter extends Naked Generic Type Parameter 
? {{type checking }} : Naked Generic Type Parameter

declare function ABC<const T extends { a: number, b: number }>(
    a: T extends T ? { a: number, b: T['a'] extends 1 ? T['b'] extends 2 ? "'b' cannot be 2 if 'a' is 1" : T['b'] : T['b'] } : T
): void

ABC({ a: 1, b: 1 }) // ok
ABC({ a: 1, b: 2 }) // no error！!!!
ABC({ a: 1, b: 3 }) // ok

this will fail too:

Naked Generic Type Parameter[] extends Naked Generic Type Parameter[] 
? {{type checking }} : Naked Generic Type Parameter

declare function ABC<const T extends { a: number, b: number }>(
    a: T[] extends T[] ? { a: number, b: T['a'] extends 1 ? T['b'] extends 2 ? "'b' cannot be 2 if 'a' is 1" : T['b'] : T['b'] } : T
): void

ABC({ a: 1, b: 1 }) // ok
ABC({ a: 1, b: 2 }) // no error！!!!
ABC({ a: 1, b: 3 }) // ok

I am not sure why but probably related to this

Use Case

If you are curious why type level custom error messages are useful, take a look at how Firelordjs and FireSageJS make Firebase Firestore and Realtime Database much easier to use

Function: The Savior of Scope. The Story Of Immutability And Declarative.

Acid Coder — Wed, 21 Jun 2023 21:14:24 +0000

You likely heard of the term Functional Programming, that it is declarative, immutable, pure function(no side effect) and it uses recursion over loop.

Immutable, declarative, pure function and recursion, we repeat these words every time we talk about functional programming

But why?

Today we are going to examine how immutability, declarative, pure function and recursion are related to each other and why we cant mention one without mentioning the rest.

Immutability

First let us review why we want to avoid mutable variables if possible by comparing it to immutable variables

Possible mistake with mutable variables:

let temperature = 30
let distance = 3000
//...others code
temperature = 2000 // mistake, you should change the distance!
// ...others code
displayTemperature(temperature) // mistake 1
displayTemperature(distance) // mistake 2

Possible mistake with immutable variables:

const temperature = 30
const distance = 3000
//...others code
temperature = 2000 // compiler will complain!!
// ...others code
displayTemperature(temperature) // no problem
displayTemperature(distance) // mistake 1

both mutable and immutable suffer from the same mistake: reading them at wrong places

This is not something compiler can take care of, you need to write tests to mitigate mistakes like this.

However, mutable variables has one extra point of failure: assigning value to a wrong variable. It can be very hard to debug because value assignment can happen in anywhere.

We can mitigate wrong variable value assignment by writing tests too, but writing tests take away our precious engineering time. Mistake like this can be prevented by using immutable variables.

Prevention is better than cure.

Declarative Code

We heard of "imperative" and "declarative" a lot, but how to tell which code is imperative and which code is declarative?

The keyword of writing a declarative code is "expression".

If we can express a piece of code as a value, then it is an expression, example:

can be expressed as a value:

condition ? 1 : 2

cannot be expressed as a value:

if(condition){
    1
} else {
    2
}

Simple enough, but how is this related to immutability?

Meaningful Value

A value has to have a purpose, else it would be pointless to create the value in the first place

so what is the purpose of a value?

Recall what computer do: accept an input, process it, and output the result

A value is only meaningful if we read it(turn the output into another input)

Turn an expression into an input:

By assigning it to a variable, preferably immutable variable:

const input = condition ? 1 : 2

doSomething(input)

By reading the expression directly:

doSomething(condition ? 1 : 2)

Turn non-expression code into an input:

By mutable variable:

let input = null

if(condition){
    input = 1
} else {
    input = 2
}

doSomething(input)

This is bad, because we need to rely on mutable variable to escape if scope

By var or global variable:

if(condition){
    var input = 1
} else {
    input = 2
}

doSomething(input)

if(condition){
    input = 1
} else {
    input = 2
}

doSomething(input)

I believe I don't need to explains why they are terrible ideas.

By running the side effect in the if scope:

if(condition){
    doSomething(1)
} else {
    doSomething(2)
}

doSomething is a side effect, it has to be one. Because in the end it either end up sending the data somewhere else or storing the data in a database or display the data on a screen(become an input of our brain).

If not, then doSomething is meaningless, our if statement is meaningless.

We coupled doSomething into the if statement. Which mean it is not possible to test the if statement without testing the side effect doSomething.

Scope `{}`

Notice that scopes {} from statements like if, try catch, switch, for, while... are the reason why we need mutable variable to access values generated in scopes.

Scope limit the access to variables, this a good mechanism but we need to sacrifice immutability.

The more we nest our scope, the more we rely on mutable variables.

Which mean scope nesting not only affect our code readability, it also affects our code correctness.

Bad readability produces bugs, bad readability and mutable variables produce even more bugs!

So should we give up on scope?

No, in fact we can create immutable variable from scopes.

Function, The Savior of Scope

Not only function scope can limit the accessibility of variables, it allow us to read a value from scopes without creating any mutable variable.

From the same example:

const getResult = (condition) => {
  if(condition){
      return 1
  } else {
      return 2
  }
}

const input = getResult(false)

doSomething(input)

checking the list:
✅ scope
✅ immutable
✅ pure function

However this does not work with loop scope, loop always end up with mutable variable or side effect.

const getSumUpToN= (n) => {
  let sum = 0 // mutation
  for(let i = 1; i <= n ;i ++){ // mutation
     sum += i
  }
  return sum   
}

const input = getSumUpToN(5)

doSomething(input)

Recursion

This is where recursion enter the picture. We can use recursion to preserve the immutability.

Function is the key to make recursion possible.

const getSumUpToN= (n) => {
   return n <= 0 ? 0 : n +  getSumUpToN(n - 1)
}

const input = getSumUpToN(5)

doSomething(input)

Now we understand why functional programming use recursion over loop, it is because recursion can express loop as an value and avoid mutable variables

We also understand why functional programming is functional, it is because function is an expression and it make recursion possible.

Summary

The foundation of functional programming is expression(value)
The tool is function. Function can turn everything into expressions by returning values from scopes and use recursion over loop.
The result is a flattened code where it is unnecessary to limit the accessibility of variables
The main benefits are immutability and pure function(improve code correctness), the extra benefit is declarative(improve readability).

Final Thoughts

I believe the point of functional programming is to remove the need of scope.

We need scope to limit accessibilities of variables in order to code safer, but at the same time scope either introduce mutable variable or couple side effects into statements.

By using function, we can maintain immutability and decouple from side effect while limiting accessibilities of variables.

I hope this article give you a clear idea of how to write a basic functional code and why you need to write one.

Stay vigilant fellow programmers!

Typescript WTF Moment 12: Beware of Object Literal Unions

Acid Coder — Tue, 20 Jun 2023 10:31:31 +0000

type ABC = { A: number, B: number } | { C: number }

const abc: ABC = { A: 1, B: 2, C: 3 } // no error!

playground

Typescript excess property check allow any property from unions of object literal

Solutions:

Assign type never to excess properties and make them optional

type ABC = { A: number, B: number, C?: never } | { A?: never, B?: never, C: number }

const abc: ABC = { A: 1, B: 2, C: 3 } // error!

const ab: ABC = { A: 1, B: 2 } // ok!

const c: ABC = { C: 3 } // ok!

const bc: ABC = { B: 2, C: 3 } // error!

playground

With common properties that have different types, Typescript is able to discriminate unions

However it is a lot of work if we have a large unions of object literal

We need to create an utility type that automate this process

type GetAllKeys<T> = T extends T ? keyof T : never

type CreateOptionalExcessProperty<T, Y> = T extends T ? T & Partial<Record<Exclude<GetAllKeys<Y>, keyof T>, never>> : never

type StrictUnion<T> = CreateOptionalExcessProperty<T, T>

type ABC = StrictUnion<{ A: number, B: number } | { C: number }>;

const abc: ABC = { A: 1, B: 2, C: 3 } // error!

const ab: ABC = { A: 1, B: 2 } // ok!

const c: ABC = { C: 3 } // ok!

const bc: ABC = { B: 2, C: 3 } // error!

playground

The purpose of T extends T is to distribute unions

credit

Write Declarative, Immutable and Flattened Code by Combining Promise and Async Await. The Great Escape From The 4 Hells

Acid Coder — Sun, 18 Jun 2023 08:53:32 +0000

(Note: Promise here refer to Promise Chain)

Try to google "mix promise and await" , the first two results tell you not to do so

The first result is basically the author forgot to await his promise.

The same error can happen if he go pure Async Await (without using any .then and .catch) and forget to await his Promise.

It doesn't matter whether he is mixing Promise and Async Await or not. If he does not await his Promise AGAIN, he is f*ked.

The 2nd result was because OP forgot to return his promise.

It doesn't matter whether he is mixing Promise and Async Await or not. If he does not return his Promise AGAIN, he is f*ked.

People quickly jump into conclusion like "it is because you mixed promise or async await" but ignoring the fact that they will repeat the same mistake with pure Promise or pure Async Await style.

Code Inconsistency...?

I get it, people like to store blue ball in a blue box. I can feel my blood boiling when I see someone threw food waste into recycle bin that was meant for plastic.

But can we stop and think, what actually make a code inconsistent?
can you write a consistent Promise code?
can you write a consistent Async Await code?
can you write a consistent Promise + Async Await code?

The answer is a 100% yes

can you write a inconsistent Promise code?
can you write a inconsistent Async Await code?
can you write a inconsistent Promise + Async Await code?

The answer is also a 100% yes

The key to write a consistent code is not only about what language APIs to use, but it is also about how we use language APIs.

We are oversimplifying code inconsistency if we think our code is inconsistent just because we are using 2 language APIs that are doing the same thing.

In this article, I am going to show you not only writing consistent Promise + Async Await code is easier than writing consistent Promise or consistent Async Await code, I will also show you why Promise + Async Await code are easier to reason with and can lead to a better code consistency.

Hells

To write a good Promise + Async Await code, we need to look at how styles of both language APIs affect our code structure and understanding each approaches weaknesses and strengths

Functionality wise, Promise and Async Await do exactly the same thing. They have similar complexity, similar readability and suffering from conceptually similar hells.

I describe Promise as horizontal, because Promise has horizontal readability and suffering from a horizontal hell

I describe Async Await as vertical, because Async Await has vertical readability and suffering from a vertical hell

Both Promise and Async Await suffer from one common hell: nesting hell

Here we are going to demonstrates all hells by using a common example, the conditions are:

We need to make 3 out bound API calls, the latter calls require the data from the previous call.
We need to handle each API call error.

Promise's Hells

Let us solve the problem with Promise and go through options that we have.

Then we analyze what make them frustrating to work with.

Callback Hell

fetchOne()
    .then(data => {
        return fetchTwo(data)
            .then(data => {
                return fetchThree(data)
                    .then(data => {
                        // handle data
                    })
                    .catch(err => {
                        // handle error
                    })
            })
            .catch(err => {
                // handle error
            })
    })
    .catch(err => {
        // handle error
    })

This is Promise's nested hell, also known as Callback Hell

You don't like it? Fine, try Bridge Hell

Bridge Hell

fetchOne()
    .catch(err => {
        // handle error
    })
    .then(data => {
        return fetchTwo(data).catch(err => {
            // handle error
        })
    })
    .then(data => {
        if (data) {
            return fetchThree(data).catch(err => {
                // handle error
            })
        }
    })
    .then(data => {
        if (data) {
            // handle data
        }
    })

Introducing Promise horizontal hell, I like to call it Bridge Hell.

We can read everything from left to right.

Other than slightly confusing and not how the usual way we read code(from top to bottom), it has no serious flaw

But some programmers may find this difficult to reason with.

Async Await's Hells

Many people believe Async Await is solution to Promise's Hell, this is due to most programmer start their journey with procedural programming, it is our habit and we love our habits dearly.

But if we look closely, Async Await does not solve anything, it has the same problem with Promise, but flipped 180 degree.

We simply jump from "I don't like this" hells to "I like this" hells.

Scope Hell

const abc = async () => {
    try {
        const data = await fetchOne()
        try {
            const data2 = await fetchTwo(data)
            try {
                const data3 = await fetchThree(data2)
                // handle data3
            } catch (e) {
                // handle error
            }
        } catch (e) {
            // handle error
        }
    } catch (e) {
        // handle error
    }
}

This is Async Await's nesting hell, I like to call it Scope Hell

And of course, if Promise has horizontal hell(Bridge Hell), then Async Await also has vertical hell, introducing Tower Hell:

Tower Hell

const abc = async () => {
    let data = null

    try {
        data = await fetchOne()
    } catch (e) {
        // handle error
        return
    }

    let data2 = null

    try {
        data2 = await fetchTwo(data)
    } catch (e) {
        // handle error
        return
    }

    try {
        const data3 = await fetchThree(data2)
        // handle data3
    } catch (e) {
        // handle error
    }
}

This is Async Await's vertical hell, also known as Tower Hell.

You may think that this actually is fine, it is not nested, it is how we usually write our code, it is from top to down, so what makes it a hell?

The reason is that it creates a mutable variable for each Promise.
This is because try catch block are not an expression. It cannot be evaluated into a value. It is not declarative.

The same reason why functional language use recursion instead of for loop because for loop is not an expression and has to rely on either mutability or side effect to be useful.

So what is wrong with mutable variables?

They are difficult to track and debug, requiring extra effort to determine when or where we mutate them.

Summarizing 4 Hells

Promise's Callback Hell
❌ hard to reason with because of nesting

Promise's Bridge Hell
✅ can read the code from left to right
❌ hard to reason with because of long method chaining

Async Await's Scope Hell
❌ hard to reason with because of nesting

Async Await's Tower Hell
✅ can read the code from top to down
❌ hard to reason with because of mutable variables

Transforming Hells into Heavens

So can we create something that is:
✅ not nested
✅ no long chain
✅ no mutable variable
✅ read the code from top to down
✅ easy to use

Due to our habit we choose to read the code from top to down rather than from left to right

This is possible by fixing existing hells.

Strategy:

Select hells to fix
Derive strategy to fix hells

Which Hells To Keep?

The answer is to keep Promise's Bridge Hell and Async Await's Tower Hell.

This is because nesting is a generic code style issue that is not limited to Promise and Async Await. So we need to completely abandon Promise's Callback Hell and Async Await's Scope Hell.

How To Fix Them?

Let us take a closer look at Promise's Bridge Hell and Async Await's Scope Hell.

Promise's Bridge Hell
✅ does not suffer from mutable variables
❌ Suffer from long method chaining

Async Await's Tower Hell
✅ does not suffer from long method chaining
❌ Suffer from mutable variables

At this point, it becomes clear that since we can mix Promise and Async Await, we can:

use Promise to create immutable variables
use Async Await to slice long chaining.

Heavenly Solution!

const abc = async () => {
    const { data, error } = await fetchOne()
        .then(data => ({ data }))
        .catch(error => ({ error }))

    if (error) {
        // handle error
        return
    }

    const { data2, error2 } = await fetchTwo(data)
        .then(data2 => ({ data2 }))
        .catch(error2 => ({ error2 }))

    if (error2) {
        // handle error
        return
    }

    const { data3, error3 } = await fetchThree(data2)
        .then(data3 => ({ data3 }))
        .catch(error3 => ({ error3 }))

    if (error3) {
        // handle error
    }
    // handle data3
}

What we need to do is await Promise and return { data } object from .then methods and { error } object from .catch methods.

Let us review the benefits:

✅ no nesting
✅ no long chain
✅ no mutable variable
✅ can read the code from top to down
✅ easy to use

Final Thoughts

Since Promise and Async Await do the same thing and conceptually similar but structurally different in terms of strengths and weakness, their relationship is actually symbiosis rather than competitive.

I hope this article inspire you to write better Promise and Async Await code.

Stay creative and innovative fellow programmers!

Translate Speech Into Japanese (open source web app)

Acid Coder — Tue, 02 May 2023 17:53:01 +0000

This web application translates speech into Japanese speech, try it at voicefu.com

Techs:

Speech to text: Whisper
Translation: GPT
Japanese Voice Synthesis: Voicevox

you can get the source source code here: https://github.com/tylim88/Voicefu

Responsive design, you can view it on phone

0 command SSH for Dummy using Bitvise Client

Acid Coder — Mon, 01 May 2023 08:28:45 +0000

download bitvise client https://www.bitvise.com/ssh-client-download

-setup your login credential using password(we use unbuntu in this example)

the server ip address
default ssh port is 22
username
password
check the box if you want to store the password
save your profile so you can reuse it

click client key manager, we will generate a new ssh profile(the key pair) general rule: client should create the key pair, not server

use default setting

optional: you can add passphrase, this is useful in case your key get stolen, but it will prompt you for passphrase every time you try to login (bitvise will not save the passphrase in profile). We will not add passphrase in this example.

export the public key

select the ssh profile you created just now
click export
export the public key in open ssh format
save it in a file, name it to anything you want, in this example, the name is yourpubkey

finally login(click the login button at the bottom) to your server using password. After login successful, click on the New SFTP window on the left bar.

go to home and create a .ssh folder

inside the .ssh folder, create a authorized_keys file

double click authorized_keys file and open it with notepad

now open yourpubkey and copy the content to authorized_keys and save authorized_keys, the content should look like this:

now we can test the ssh connection, logout(click log out at the bottom) the current session and try to login with ssh. Change the method to public key and use auto client key

you should be able to login now, enjoy!

If you want to add new public key to your server, open the same authorized_keys file, append the new key one line under the old key

extra:
you may want to disable password login

edit the ssh config
sudo nano /etc/ssh/sshd_config
find this line
#PasswordAuthentication yes
change it to (remember to remove the #)
PasswordAuthentication no
save the file and restart ssh
sudo systemctl restart ssh

make sure your ssh is working before you try to disable password login!

Typescript Loop Tuple With Length > 1000

Acid Coder — Sat, 24 Dec 2022 23:23:33 +0000

We cannot recurse tuple with more than 1000 length due to TS limitation

In this example we try to feed a recursion utility RebuildTuple with 9990 length tuple

type CreateArrayWithLengthX<
    LENGTH extends number,
    ACC extends unknown[] = [],
> = ACC['length'] extends LENGTH
    ? ACC
    : CreateArrayWithLengthX<LENGTH, [...ACC, 1]>

type Exceed999<
    ARR extends 1[],
> = [...ARR['length'] extends 0 ? [] : [...CreateArrayWithLengthX<999>, ...Exceed999<ARR extends [...infer S extends 1[], infer P] ? S : never>]]

// create 9990 length array
type Tuple9990 = Exceed999<CreateArrayWithLengthX<10>>

type RebuildTuple<T extends unknown, ACC extends unknown[] = []> = T extends [infer S, ...infer R] ? RebuildTuple<R, [...ACC, S]> : ACC

type C = RebuildTuple<Tuple9990>

TS will complains

playground

reference:create tuple with more than 1000 length

However we can use the mapped type to loop the tuple:

type RebuildTuple<T extends unknown> ={ [K in keyof T] : T[K] }

playground
no error

let us do further comparison by using it in function generic:

type RebuildTuple<T extends unknown, ACC extends unknown[]= [] >= T extends [infer S, ...infer R] ? RebuildTuple<R,[...ACC,S]>: ACC
type RebuildTuple1<T extends unknown[]> = { [K in keyof T]: T[K] }


type A = RebuildTuple<[1,2,3]>
//   ^?
type A1 = RebuildTuple1<[1,2,3]>
//   ^?

const abc=<T extends unknown[]>(v:T extends never ? T : RebuildTuple<T>)=>{}
const abc1=<T extends unknown[]>(v:T extends never ? T : RebuildTuple1<T>)=>{}

abc([1,2,3])
//^?
abc1([1,2,3])
//^?

playground

It can't infer the type, what is wrong?

This is because we forgot to narrow the type in RebuildTuple1 down to a tuple

type RebuildTuple<T extends unknown, ACC extends unknown[]= [] >= T extends [infer S, ...infer R] ? RebuildTuple<R,[...ACC,S]>: ACC
type RebuildTuple1<T extends unknown[]> = T extends [ infer S,...infer R] ? { [K in keyof [S,...R]] : [S,...R][K] } : never


type A = RebuildTuple<[1,2,3]>
//   ^?
type A1 = RebuildTuple1<[1,2,3]>
//   ^?

const abc=<T extends unknown[]>(v:T extends never ? T : RebuildTuple<T>)=>{}
const abc1=<T extends unknown[]>(v:T extends never ? T : RebuildTuple1<T>)=>{}

abc([1,2,3])
//^?
abc1([1,2,3])
//^?

playground

the hint doesn't look pretty

but they are indeed the same thing

DEV Community: Acid Coder

Stop using Eslint and Prettier, use Biomejs instead! End Bike Shedding, End Endless Configurations!

TS-Hajime: Effortlessly Bootstrap TypeScript NPM Libraries

Typescript Flatten Object Type

Typescript Nominal Type: The Right Way

BUT THIS IS NOT GOOD ENOUGH !!

Solution

Typescript Type Level Custom Error Message For Utility Types

Typescript Type Level Custom Error Message, Move Runtime Error to Compile time Error!

How Does It Works?

Object Literal Type

Use Case

Function: The Savior of Scope. The Story Of Immutability And Declarative.

Immutability

Declarative Code

Meaningful Value

Turn an expression into an input:

Turn non-expression code into an input:

Scope {}

Function, The Savior of Scope

Recursion

Summary

Final Thoughts

Typescript WTF Moment 12: Beware of Object Literal Unions

Solutions:

Write Declarative, Immutable and Flattened Code by Combining Promise and Async Await. The Great Escape From The 4 Hells

Code Inconsistency...?

Hells

Promise's Hells

Callback Hell

Bridge Hell

Async Await's Hells

Scope Hell

Tower Hell

Summarizing 4 Hells

Transforming Hells into Heavens

Which Hells To Keep?

How To Fix Them?

Heavenly Solution!

Final Thoughts

Translate Speech Into Japanese (open source web app)

0 command SSH for Dummy using Bitvise Client

Typescript Loop Tuple With Length > 1000

Scope `{}`