kakasoo

declare function PromiseAll(values: readonly [...T]): Promise 배열도 객체라고 생각하면 그 key들은 그 배열의 length까지의 숫자들로 이루어지게 되기 때문에 그 키에 대한 값을 Awaited로 감싼 객체로 정의한다.

type TrimLeft = S extends ` ${infer Rest}` | `\n${infer Rest}` | `\t${infer Rest}` ? TrimLeft : S; type TrimRight = S extends `${infer Rest} ` | `${infer Rest}\n` | `${infer Rest}\t` ? TrimRight : S; type Trim = TrimRight; TrimLeft, Right를 구현한 후 이를 합성하는 것이 훨씬 더 쉽다. 처음에는 쓸 데 없는 욕심에 Trim을 extends로 쭉 나열했는데 가독성만 나빠졌다.

type TrimRight = S extends `${infer Left} ` | `${infer Left}\n` | `${infer Left}\t` ? TrimRight : S; 이걸 풀고 나니 TrimLeft를 더 쉽게 풀 수 있었을 것 같다.

type TrimLeft = S extends `${infer R}${infer Rest}` ? R extends ' ' | '\n' | '\t' ? TrimLeft : S : ''; string이 `${infer R}${infer Rest}` 일 때, R은 첫번째 글자가 되고 Rest는 나머지 모든 글자가 된다. 따라서 R이 빈 문자일 경우에는 Rest를 다시 재귀적으로 TrimLeft로 호출해주면 된다. R이 빈 문자가 아닐 경우에는 TrimLeft할 게 없으니 종료 시점으로 보고 S를 리턴하면 된다. 만약 string이 `${infer R}${infer Rest}`의 형식이 아닐 경우는 빈 문자이기 때문에 빈 문자를 리턴하면 된다.

type Flatten = T extends [infer R, ...infer Rest] ? R extends any[] ? [...Flatten, ...Flatten] : [R, ...Flatten] : []; 배열인지 아닌지에 따라 재귀적으로 풀 것인지 결정하면 된다. 만약 T가 infer R과 infer Rest로 구성된 배열일 때, R이 배열인지 아닌지에 따라 재귀적으로 접근하면 된다. Rest는 나머지 요소들이기 때문에 무조건 배열이며 따라서 재귀적으로 접근하면 된다. 만약 T가 이러한 배열이 아닐 경우에는 빈 배열이 된다.

type DeepReadonly = { readonly [K in keyof T]: T[K] extends ((...args:any[]) => any) ? T[K] : T[K] extends Record ? DeepReadonly: T[K] extends Array ? DeepReadonly : T[K]; } 타입을 재귀적으로 정의해야 한다는 것은 간단하지만, 그럼에도 빨간 줄이 사라지지 않아서 조금 헤맸다. 타입추론된 결과를 보니 함수도 객체라서 문제가 생긴 걸 파악할 수 있었고, 따라서 맨 앞에 extends를 하나 더 추가해 함수를 처리했다. 결과적으로 extends가 3개가 되었는데 이게 좋은 코드일까? type DeepReadonly = keyof T extends never ? T : { re..

import * as ts from "typescript"; // TypeScript 파일을 읽어들입니다. const sourceFile = ts.createSourceFile( "example.ts", ` const num: number = 42; const str: string = "Hello, TypeScript!"; const bool: boolean = true; `, ts.ScriptTarget.Latest ); // 타입 체커를 생성합니다. const program = ts.createProgram({ rootNames: ["example.ts"], options: { target: ts.ScriptTarget.ES2015, module: ts.ModuleKind.CommonJS, }, })..

잘 만들어진 테스트 코드는 일종의 spec, 즉 명세서의 역할을 수행할 수 있어야 한다. 또한 잘 만들어진 테스트는, 코드 설계에 앞서 개발자 간의 커뮤니케이션을 위한 도구로 사용될 수 있어야 한다. 여기서 말하는 개발자는 백엔드 개발자만이 아니라, API를 다루는 모든 관계자를 말한다. 디자인을 이야기하기 위해서는 기획서가 필요하듯이, 개발자들도 개발을 위한 기반 지식들이 필요하다. 이 지식은 단순히 개발을 위한 도메인 지식이 아니라, 서로 간의 이해가 일치하는지 확인하는 일을 포함한다. 테스트 코드는 여기서 이 일치 확인, 전체 프로그램 작성에 일관성을 확보하는 작업을 위한 것이라 볼 수 있겠다. 테스트 코드 (spec) 작성 /** * 게시글에 대한 좋아요/좋아요 취소 */ describe('PAT..

최근에 읽은 책에서 본 글귀가 강한 인상을 남긴다. 지인이 오랜만에 메시지를 남겼다. 고민 상담을 하고 싶은데 전화 좀 해도 되겠냐고 하셨다. 자기 공부를 하겠다고 잠깐 멀리 나가 계신 분이셨는데 이 분은 나와의 관계도 매우 좋은 분이었다. 그래서 고민이라는 단어보다도 그저 오랜만에 연락이 왔다는 점에 더 눈이 갔다. 나는 무척이나 반가운 마음에, 괜찮다고 말하는 대신에 바로 전화를 걸었다. 어떤 고민일까 흥미가 동할 시점, 상대가 최근 너무 힘들다고 우는 게 아닌가. 아뿔싸, 고민이라더니 진짜로 심각한 상태였구나. 나는 내가 상대의 고민을 가볍게 생각했다는 걸 뒤늦게 깨달았다. 나는 상대를 달래주고, 그런 일로 힘들어하지 말라고 말해주었다. 어떤 위로도 지금의 힘든 순간을 희석해주지는 못하겠지만, 아무..

GitHub - type-challenges/type-challenges: Collection of TypeScript type challenges with online judge Collection of TypeScript type challenges with online judge - GitHub - type-challenges/type-challenges: Collection of TypeScript type challenges with online judge github.com type MyReturnType = T extends (...args:any[]) => infer R ? R : never; 어떤 타입 T를 정의할 때, 그 T에 대한 정의는 반드시 제너릭 쪽에 되어야 할 필요가 없다. 제..

[Feature request]type level equal operator · Issue #27024 · microsoft/TypeScript Search Terms Type System Equal Suggestion T1 == T2 Use Cases TypeScript type system is highly functional. Type level testing is required. However, we can not easily check type equivalence. I want a... github.com 글에서 Equals을 어떻게 설명하는지 나와있다. 다만, 완벽한 정의가 아니고, 대부분의 상황에 적합한 것이기 때문에 유틸리티 타입에 포함되지는 않는 것 같다. export type Equ..

이번에 테스팅할 API는? import { TypedBody, TypedRoute } from '@nestia/core'; import { Controller } from '@nestjs/common'; import { JwtService } from '@nestjs/jwt'; import { createResponseForm, ResponseForm } from '../interceptors/transform.interceptor'; import { CreateUserDto } from '../models/dtos/create-user.dto'; import { DecodedUserToken } from '../models/tables/user.entity'; import { UsersService }..