💡타입스크립트 성능을 위한 몇 가지 팁 💡

컴파일하기 쉬운 코드를 작성하기

📌 타입간 결합이 필요하다면 type대신 interface 사용하기

interface Foo {
  prop: string
}

type Bar = { prop: string }

객체에 사용하는 type과 interface는 매우 유사하게 사용되고 있다.

그러나 타입간 결합이 필요할 때는, interface를 확장하는 것이 성능상으로 유리하다.

interface는 단순히 객체에 대한 모양을 표현하는 것이기 때문에, 여러개가 올 경우 단순히 합쳐버리면 된다.

그러나 type은 객체 뿐 만 아니라 단순히 원시타입도 올 수 있기 때문에 병합할 때 객체의 속성들까지 하나하나 합쳐야 한다.(재귀적인 타입 머지) 특히, 객체 안에 또 다른 객체가 있을 때, 그 내부 속성까지 다 합쳐야해서 때때로 never을 반환하기도 한다.

type A = { a: string };  // A의 'a' 속성은 string 타입.
type B = { a: number };  // B의 'a' 속성은 number 타입.

서로 다른 타입을 병합할 때 타입이 충돌하면 never 타입이 오게 된다.

-> 따라서 여러개의 객체 타입을 합성해야 한다면, interface의 extends를 사용하는 것이 좋다.

📌 타입 어노테이션 사용하기

직접 리턴타입을 지정해준다면 타입스크립트 컴파일러가 함수의 타입을 추론하는 것 보다 훨씬더 성능적으로 이점을 얻을 수 있다.

declaration 파일을 읽고 쓰는데 많은 시간을 절약해준다. (incremental builds) 물론 타입 추론은 매우 편리한 기능이기 때문에, 다 이걸 처리할 필요는 없지만, 코드에서 약간의 병목현상이 생긴다면 고려해볼만 하다.

변수에 타입 어노테이션

let name: string = "Alice"; // name 변수는 string 타입이어야 한다고 명시
let age: number = 25;       // age 변수는 number 타입이어야 한다고 명시

함수에 타입 어노테이션

function greet(name: string): string {
 //  greet은 매개변수 name이 string 타입이어야 하고, 반환 값도 string 타입 명시
    return `Hello, ${name}`;
}

-> 리턴타입을 지정

📌 Union 보다는 Base type을 만들어두자

타입 union은 값에 대한 다양한 타입의 가능성을 열어주지만, 비용이 발생한다.

interface WeekdaySchedule {
  day: 'Monday' | 'Tuesday' | 'Wednesday' | 'Thursday' | 'Friday'
  wake: Time
  startWork: Time
  endWork: Time
  sleep: Time
}

interface WeekendSchedule {
  day: 'Saturday' | 'Sunday'
  wake: Time
  familyMeal: Time
  sleep: Time
}

declare function printSchedule(schedule: WeekdaySchedule | WeekendSchedule)

printSchedule에 인수가 넘어갈 때마다, 각 인수들을 union에 있는 타입들과 대조하기 시작한다. 물론 단순히 타입이 두개 뿐이라면 (성능적인 차이는) 무시할만하다. 그러나 이 숫자가 많아진다면, 컴파일 속도에 문제가 될 수 있다. 예를 들어, union에서 중복을 제거하기 위해 각각의 요소를 쌍으로 비교해야 하며, 이는 2차적으로 드는 비용이다. 이러한 종류의 검사는 union이 커질 수록 더욱 많이 발생할 수 있으며, 이 규모를 줄여야 한다. 이를 위해 union 보다는 하위 유형을 사용하는 것이 좋다.

interface Schedule {
  day:
    | 'Monday'
    | 'Tuesday'
    | 'Wednesday'
    | 'Thursday'
    | 'Friday'
    | 'Saturday'
    | 'Sunday'
  wake: Time
  sleep: Time
}

interface WeekdaySchedule extends Schedule {
  day: 'Monday' | 'Tuesday' | 'Wednesday' | 'Thursday' | 'Friday'
  startWork: Time
  endWork: Time
}

interface WeekendSchedule extends Schedule {
  day: 'Saturday' | 'Sunday'
  familyMeal: Time
}

declare function printSchedule(schedule: Schedule)

-> 공통적인 부모 타입을 만들어서 상속하는 방식으로 구조를 단순화 하자! 이렇게 하면 TypeScript가 유니온에서 매번 타입을 비교하는 일을 줄일 수 있어 성능이 개선될 수 있다.

📌 프로젝트 레퍼런스 사용하기

프로젝트의 크기와 구조는 적절한 수준에서 균형을 잡아야 한다. 프로젝트가 너무 크면 관리하기 어려워지고, 너무 작으면 효율성이 떨어져서 오히려 불필요한 작업이 많아질 수 있다. 관련된 파일끼리 묶고, 적절한 단위로 프로젝트를 나누는 것이 이상적이다.

JS와 TS를 폴더로 나눈다

프로젝트에서 JavaScript 파일과 TypeScript 파일을 폴더로 구분하여 정리하는 것이 좋다.

같은 폴더에 있는 코드의 내용은 유사해야 한다

기능이 비슷하거나 관련된 코드들은 같은 폴더 안에 묶는 게 좋다. 관련이 없는 코드가 섞여 있으면 나중에 유지보수가 어려워질 수 있다.

프로젝트가 너무 크거나 작으면 좋지 않다

너무 큰 프로젝트
하나의 프로젝트가 다른 모든 프로젝트보다 훨씬 크면, 이는 프로젝트의 복잡도가 너무 높아졌다는 경고 신호로 볼 수 있다. 이런 경우 프로젝트를 더 작은 단위로 나누는 것이 좋다.

너무 작은 프로젝트
한두 개의 파일만을 가지고 수십 개의 프로젝트로 쪼개면, 오히려 오버헤드가 생겨서 관리하기 어려워진다. 비효율적

프로젝트의 크기는 적절해야한다. 너무 크지도, 너무 작지도 않게 적절한 크기를 유지하는 것이 중요합니다. 이건 마치 "함수나 클래스가 너무 크면 관리하기 힘들고, 너무 작으면 불필요하게 코드가 분리된다"는 것과 비슷한 원리이다.

📌 tsconfig.json이나 jsconfig.json 설정하기

파일 명시하기

항상 설정파일이 한번에 너무 많은 파일을 포함하지 않도록 조심해야 한다.

tsconfig.json을 사용한다면, 프로젝트의 파일을 특정하는 방법이 두가지가 있다.

files

include exclude

files는 파일 경로를 직접 지정하는 방식
장점: 파일을 빠르게 로드할 수 있음.
단점: 프로젝트 파일이 많아지면 번거로울 수 있다. 새로운 파일을 추가할 때마다 설정 파일(tsconfig.json)에 일일이 추가해야 할 수도 있다.

include/exclude는 글로빙 패턴을 사용해 특정 폴더나 파일을 포함하거나 제외하는 방식이다.
장점: 파일을 일일이 지정하는 번거로움을 덜어준다.
단점: TypeScript가 디렉토리를 모두 순회해야 하기 때문에, 폴더가 많으면 컴파일 속도가 느려질 수 있다. 필요 없는 .d.ts나 테스트 파일이 포함되면 메모리와 컴파일 속도에 영향을 줄 수 있다.

exclude는 기본적으로 node_modules 같은 대규모 폴더를 제외하지만, 이를 잘 관리하지 않으면 무거운 폴더가 포함될 수 있다.

이 내용은 TypeScript의 tsconfig.json 설정 파일에서 files와 include/exclude 옵션을 어떻게 설정하는지, 그리고 각각의 장단점과 최적의 설정 방법에 대해 설명하고 있어요. 이를 쉽게 요약해볼게요:

요약:
files는 파일 경로를 직접 지정하는 방식이야.

장점: 파일을 빠르게 로드할 수 있음.
단점: 프로젝트 파일이 많아지면 번거로울 수 있음. 새로운 파일을 추가할 때마다 설정 파일(tsconfig.json)에 일일이 추가해야 할 수도 있음.
include/exclude는 글로빙 패턴을 사용해 특정 폴더나 파일을 포함하거나 제외하는 방식이야.

장점: 파일을 일일이 지정하는 번거로움을 덜어줌.
단점: TypeScript가 디렉토리를 모두 순회해야 하기 때문에, 폴더가 많으면 컴파일 속도가 느려질 수 있음. 필요 없는 .d.ts나 테스트 파일이 포함되면 메모리와 컴파일 속도에 영향을 줄 수 있음.
exclude는 기본적으로 node_modules 같은 대규모 폴더를 제외하지만, 이를 잘 관리하지 않으면 무거운 폴더가 포함될 수 있음.

최적의 설정 방법
1. 프로젝트의 소스 파일이 있는 폴더만 명시한다. (예: src 폴더)
2. 다른 프로젝트의 소스 파일과 섞이지 않게 폴더를 잘 구분한다.
3. 테스트 파일은 원본 파일과 같은 폴더에 두되, 쉽게 제외할 수 있도록 고유한 이름 패턴(예: *.test.ts)을 사용한다.
node_modules나 대규모 빌드 파일들은 소스 디렉토리에 포함시키지 말자.

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

최상의 개발 경험을 위해 폴더를 잘 정리하고, 불필요한 파일을 제외하는 설정을 잘 해두는 것이 중요하다.

@types

TypeScript는 node_modules 폴더에 있는 @types 패키지를 자동으로 불러와서 사용한다. 개발자가 특정 라이브러리를 명시적으로 import하지 않아도, 그 라이브러리의 타입 정의가 프로젝트에 자동으로 로드될 수 있다.

예를 들어, node_modules 폴더에 @types/node, @types/jasmine, @types/mocha 같은 타입 정의 패키지가 있을 때, TypeScript는 이를 자동으로 포함한다.
이렇게 되면, 개발자가 직접 사용하지 않는 라이브러리(jasmine이나 mocha 같은 테스트 라이브러리)의 타입도 자동으로 로드될 수 있다.

🤔 여기서 문제점?

파일 속도 저하 -> 컴파일 시간이나 코드 편집기(IDE)의 자동 완성 기능 느려짐
타입 충돌 -> 타입이 겹쳐서 충돌이 발생

😮 해결
글로벌 패키지가 필요하지 않은 상황이라면, type 옵션을 비워 둠으로써 이러한 문제를 해결할 수 있다.

// src/tsconfig.json
{
 "compilerOptions": {
   // ...

   // Don't automatically include anything.
   // Only include `@types` packages that we need to import.
   "types": []
 },
 "files": ["foo.ts"]
}

만약 몇가지 패키지가 글로벌로 필요하다면, 아래와 같이 추가할 수 있다.

// tests/tsconfig.json
{
  "compilerOptions": {
    // ...

    // Only include `@types/node` and `@types/mocha`.
    "types": ["node", "mocha"]
  },
  "files": ["foo.test.ts"]
}

TypeScript는 기본적으로 node_modules에 있는 @types 패키지를 자동으로 포함시켜, 개발자가 import하지 않은 라이브러리의 타입도 프로젝트에 로드된다. 그래서 type은 비워두거나 필요한 부분만 넣는다.

📌 점진적 프로젝트 빌드 옵션 사용하기

--incremental 옵션을 사용하면, TypeScript는 이전 컴파일 정보를 .tsbuildinfo 파일에 저장한다. 이 파일은 이전 컴파일 이후에 변경된 파일만 다시 체크하고 컴파일해서 전체 프로젝트를 매번 새로 컴파일할 필요가 없도록 해준다. 즉, 최소한의 변경된 파일만 컴파일한다. TypeScript가 변경 사항만 컴파일하기 때문에, 컴파일 속도가 빨라지는 장점이 있다.

--incremental 옵션은 변경된 파일만 컴파일해서 컴파일 속도를 개선하는 기능입니다.
composite 설정을 사용하면 여러 프로젝트에서도 동일한 방식으로 컴파일 속도를 향상시킬 수 있어요.

📌 .d.ts 체크 생략

기본값으로, 타입스크립트는 프로젝트 내에 있는 .d.ts 파일을 모두 체크하여 일관성을 유지하고 이슈를 찾는다. 그러나, 이는 일반적으로 불필요한 작업이다. 대부분의 경우, .d.ts는 잘 작동하는 파일일 가능성이 크다. 타입스크립트는 .d.ts의 체크를 끄는 skipDefaultLibCheck 옵션을 제공한다. (이는 deprecated되었다. 그냥 skipLibCheck을 쓰면 된다.)

📌 빠른 분산 검사

interface Animal {}
interface Dog extends Animal {}
interface JayG extends Dog {}

우리가 동물(Animal), 강아지(Dog), 그리고 JayG(강아지의 한 종류)를 다루고 있다. 각 타입(Animal, Dog, JayG)이 있고, 이들이 타입 간의 관계를 어떻게 처리할 수 있을까?

Covariance

Covariance는 강아지가 동물의 한 종류니까 강아지를 동물로 사용할 수 있다는 개념이다. 즉, 하위 타입인 강아지를 상위 타입인 동물로 취급할 수 있다.

function hello(d: Dog) {}

let dog: Dog = { name: 'hi', kind: 'mix' }
let jayg: JayG = { name: 'hi', kind: 'mix', age: 34 }

hello(dog) // ok
hello(jayg) // ok

강아지를 기대하는 함수 hello에 강아지(Dog)뿐만 아니라, 강아지의 한 종류인 JayG도 넣을 수 있다.

Contravariance

상위 타입인 동물을 하위 타입인 강아지로 처리한다. 말이 어렵지만, 상위 타입을 하위 타입처럼 다룰 수 있는 경우를 말한다.

function helloDog(d: Dog) {
  console.log("강아지와 인사해요!");
}

function helloAnimal(a: Animal) {
  console.log("동물과 인사해요!");
}

helloDog = helloAnimal;  // OK! 동물과 인사하는 함수는 강아지와도 인사할 수 있어
helloAnimal = helloDog;  // Error! 강아지와 인사하는 함수가 모든 동물과 인사할 수는 없어요

1. 동물이 필요한 곳에 강아지를 넣는 건 안 된다.
2. 하지만, 강아지가 필요한 곳에 동물을 넣는 건 가능하다. 왜냐하면 동물은 강아지보다 더 넓은 범위를 포함하기 때문이다.

Invariance

른 타입을 허용하지 않는 경우. 강아지면 강아지만, 동물이면 동물만. 이건 서로 다른 타입을 섞어서 사용할 수 없다는 의미이다.

Bivariance

아무 타입이나 다 허용한다.

🤔 그래서 ?

strictFunctionTypes

옵션을 켜면 함수의 인수를 더 엄격하게 관리해서, 실수를 줄이고 컴파일을 빠르게 할 수 있다! (매수 타입의 매개변수에 대해 Contravariance을 강제한다.)

📌 tsc 만 단독으로 실행해보기

대부분의 시간을, 써드 파티 툴인 Gulp, Rollup, Webpack 등과 함께 실행하기 때문에 성능이 느려보일 수 있다. tsc --extendedDiagnostics 를 사용하여 타입스크립트와 툴간의 주요 불일치를 찾아 낸다면, 잘못된 설정 또는 비효율적인 부분을 짚어낼 수 있다.

이를 통해 염두해야 할 점은

tsc 단독 실행과 타입스크립트와 연동한 다양한 빌드 툴 사이에 빌드 시간 차이가 현격하게 나는지
빌드 툴이 진단을 제공하는 경우, 타입스크립트의 결과와 차이가 있는지
빌드 툴에 원인이 될 수 있는 자체 옵션이 있는지
빌드 툴에 원인이 될 수 있는 타입스크립트 구성이 있는지 (ts-loader 와 같이)이다.

공식 레포 참고
https://github.com/microsoft/TypeScript/wiki/Performance