1.시스템&인프라/개발환경

TypeScript 개발 환경 세팅 : tsconfig.json, tsx, Vitest

쿼드큐브 2025. 12. 5. 08:38
반응형
반응형

 

TypeScript 개발 환경 세팅 : tsconfig.json, tsx, Vitest

 

📚 목차
1. TypeScript 설치와 tsconfig.json 핵심 설정
2. TypeScript 실행 환경 구축: tsx 기반 개발
3. 테스트 환경 설정(Vitest 기반)
✔ 마무리

 

TypeScript 실무환경 세팅
TypeScript 실무환경 세팅

 

1. TypeScript 설치와 tsconfig.json 핵심 설정

백엔드 프로젝트에서 TypeScript는 단순한 선택 사항이 아니라 “서비스 안정성의 핵심 요소”로 자리 잡았습니다.

명확한 타입 시스템은 API 계약을 안정적으로 유지하고, 런타임 오류를 사전에 방지하며, 장기적으로 유지보수 비용을 크게 줄여줍니다.
2025년 기준으로 Node.js는 ES Modules(ESM)을 공식 권장하고 있고, TypeScript 역시 이러한 흐름에 맞춰 최신 기능을 제공하고 있습니다.

따라서 프로젝트 초기 단계에서 올바른 TS + ESM 환경을 구성하는 것이 무엇보다 중요합니다.

 

🔷 프로젝트 초기화 및 TypeScript 설치

1. 프로젝트를 위한 기본 디렉토리를 만들고 초기화합니다.

mkdir backend-service
cd backend-service
npm init -y

 

2. TypeScript 컴파일러를 개발 의존성으로 설치합니다.

# TypeScript 컴파일러 + 언어 서비스 패키지
# TypeScript 언어 그 자체
npm install -D typescript

# Node.js 내장 API 타입 정의 파일 패키지
# Node.js API 사용을 위한 타입 설명서
npm install -D @types/node

TypeScript 의존성 설치 화면
TypeScript 의존성 설치 화면

 

3. TypeScript 프로젝트를 시작하기 위해 기본 설정 파일을 생성합니다.

npx tsc --init

 

 

🔷 tsconfig.json 핵심 옵션 설정

{
  // 📌 TypeScript 5.9 기준 tsconfig 템플릿
  // 백엔드(Node.js ESM) 환경에 맞추어 정리한 설정입니다.

  "compilerOptions": {
    // ------------------------------------------------------------
    // 📁 File Layout
    // 프로젝트의 소스 경로와 빌드 출력 경로를 명확히 하고 싶을 때 사용합니다.
    // 백엔드 서비스는 일반적으로 src → dist 구조를 사용합니다.
    // ------------------------------------------------------------
    "rootDir": "./src",
    "outDir": "./dist",

    // ------------------------------------------------------------
    // 🧭 Path Alias 설정 (실무 필수 강력 추천)
    // ------------------------------------------------------------
    // baseUrl: TS가 import 경로를 해석할 기준 루트
    //   ✔ src를 기준 경로로 사용
    "baseUrl": "src",
    "paths": {
    // 예: @app/server → src/app/server.ts
    "@app/*": ["app/*"],
    // 예: @config/env → src/config/env.ts
    "@config/*": ["config/*"],
    // 예: @utils/logger → src/utils/logger.ts
    "@utils/*": ["utils/*"],
    // 예: @services/user.service → src/services/user.service.ts
    "@services/*": ["services/*"]
    },

    // ------------------------------------------------------------
    // 🌐 Environment Settings (환경 설정)
    // module: Node.js의 ESM/CJS 해석 규칙을 그대로 따르는 설정입니다.
    //  - nodenext: Node.js 20+의 ESM 처리 방식을 TS가 따라가게 함
    //  - 백엔드에서 Node 런타임 호환성이 매우 중요할 때 적합
    // moduleResolution: import 경로를 어떻게 해석할지 결정
    //  - bundler : Vite / tsx / tsup 같은 빌드 툴 규칙 (확장자 생략 OK)
    // ------------------------------------------------------------
    // 순수 Node.js 백엔드 서비스, 서버/마이크로서비스
    //"module": "nodenext",
    //"moduleResolution": "nodenext",

    // tsx 사용 시에는 "module": "ESNext" + "moduleResolution": "bundler"가 더 부드럽습니다.
    "module": "ESNext",
    "moduleResolution": "bundler",

    // target: 출력되는 JS 문법 수준 (Node 18~20은 ES2022 이상 권장)
    // esnext는 최신 JS 문법을 그대로 사용
    "target": "ES2022",

    // lib: Node.js 환경에서 필요한 전역 기능 제공 (fetch 등 포함)
    //      어떤 JavaScript 표준/전역 기능을 사용할지 결정
    "lib": ["ES2022"],

    // Node.js 환경에서는 @types/node가 필요합니다.
    // types 배열에 node를 명시하면 TS가 Node 전역 타입(fs, path 등)을 인식합니다.
    "types": ["node", "vitest/globals"],

    // ------------------------------------------------------------
    // 📦 Other Outputs (빌드 출력 옵션)
    // sourceMap: 디버깅 시 원본 TS 파일을 추적하기 위해 필요
    // declaration: 라이브러리 공개 목적이 아니면 선택적
    // 백엔드 서비스라면 d.ts가 꼭 필요하지는 않지만 유지해도 무방
    // ------------------------------------------------------------
    "sourceMap": true,
    "declaration": false, // 백엔드 서비스는 보통 d.ts 필요 없음
    "declarationMap": false,

    // ------------------------------------------------------------
    // 🔍 Stricter Typechecking Options (엄격한 타입 검사)
    // 서비스를 안정적으로 운영할 때 매우 유용합니다.
    // ------------------------------------------------------------

    // 배열/객체 인덱스 접근 시 undefined 가능성을 항상 포함
    // (코드는 길어지지만 안전성이 크게 올라감)
    // 이 옵션은 실무에서 거의 사용되지 않습니다.
    // "noUncheckedIndexedAccess": true,

    // 선택적 프로퍼티를 정확하게 구분
    // { a?: string } → 'a: undefined'와 'a 미존재'를 엄격히 구분
    "exactOptionalPropertyTypes": true,

    // ------------------------------------------------------------
    // 🎨 Style Options (스타일/코드 규칙)
    // 아래 옵션들은 추천되지만 필요에 따라 켜거나 끌 수 있습니다.
    // ------------------------------------------------------------
    // "noImplicitReturns": true,
    // "noImplicitOverride": true,
    // "noUnusedLocals": true,
    // "noUnusedParameters": true,
    // "noFallthroughCasesInSwitch": true,

    // ------------------------------------------------------------
    // 👍 Recommended Options (추천 옵션)
    // 백엔드 실무에서 거의 필수에 가까운 설정들입니다.
    // ------------------------------------------------------------

    // TS의 가장 엄격한 타입 검사 모드 활성화
    "strict": true,

    // 백엔드 환경에서는 JSX를 사용하지 않으므로 제거
    // "jsx": "react-jsx",

    // import/export 문법을 변환하지 않고 원본 그대로 유지
    // ESM 환경에서 문제를 예방하기 좋음
    // 그래서 “타입만 필요한 import”를 반드시 import type으로 표시하도록 요구합니다.
    "verbatimModuleSyntax": true,

    // 파일을 독립된 모듈로 간주하여 ESM 환경 오류를 예방
    "isolatedModules": true,

    // 사이드 이펙트를 일으키는 import를 엄격하게 검사
    "noUncheckedSideEffectImports": true,

    // TypeScript가 모듈을 감지하는 방식을 강제로 모듈로 설정
    "moduleDetection": "force",

    // 외부 라이브러리 타입 검사 스킵 (실무에서 속도 향상 + 안정적)
    "skipLibCheck": true
  },

  // ------------------------------------------------------------
  // 📌 include / exclude
  // 컴파일 대상과 제외할 파일/디렉토리를 명확히 설정
  // ------------------------------------------------------------
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

 

 

🔷 VS Code 개발 환경 최적화(.vscode/settings.json)

{
  "typescript.tsdk": "node_modules/typescript/lib",
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "files.eol": "\n"
}

▸ 프로젝트 로컬 TypeScript 버전 사용

→ 모든 팀원이 동일한 TS 버전으로 작업하므로 타입 오류 차이가 발생하지 않습니다.
▸ 저장 시 자동 포맷

→ 코드 스타일이 자동으로 통일됩니다.
▸ Prettier를 기본 포매터로 고정

→ 최신 JS/TS 스타일 가이드와 호환되는 안정적인 포맷 방식 제공.
▸ EOL(Line Ending) 통일
→ Git에서 OS마다 다른 개행 문자 충돌을 방지합니다.

반응형

 

2. TypeScript 실행 환경 구축: tsx 기반 개발

과거에는 ts-node를 사용해 TypeScript 파일을 실행하는 방식이 널리 사용되었지만, 현재 백엔드 실무에서는 tsx가 사실상의 표준 실행기가 되었습니다.


tsx는 다음과 같은 이유로 현대적인 실행 환경에서 필수 도구로 자리 잡았습니다.

▸ 빌드 없이 즉시 실행 (Zero-compile TS execution)
▸ ESM 완전 지원 (Node.js ESM · TS ESM 모두 자연스럽게 작동)
▸ 매우 빠른 실행 속도 (esbuild 기반 TS 변환기)
▸ ts-node의 ESM 호환 문제를 완전히 해결
▸ 실무에서 가장 간단한 개발자 경험(DX) 제공

 

🔷 tsx 설치 및 기본 실행

1. tsx는 개발 의존성으로 프로젝트에 설치합니다.

npm install -D tsx

 

2. 테스트 코드 작성: index.ts

// ./src/index.ts
import http from "node:http";
const PORT = process.env.PORT ? Number(process.env.PORT) : 3000;
const server = http.createServer((req, res) => {
  if (req.url === "/health" && req.method === "GET") {
    const response = {
      status: "ok",
      timestamp: new Date().toISOString()
    };
    res.writeHead(200, {
      "Content-Type": "application/json"
    });
    res.end(JSON.stringify(response));
    return;
  }

  // 기본 응답
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello from TypeScript + tsx server!");
});

// 서버 시작
server.listen(PORT, () => {
  console.log(`🚀 Server is running on http://localhost:${PORT}`);
});

 

3. 설치 후 TypeScript 파일을 바로 실행할 수 있습니다.

> npx tsx ./src/index.ts
🚀 Server is running on http://localhost:3000

 

✔️ 이렇게 간단해지는 이유

tsx는 내부적으로 다음 과정을 자동 처리합니다:

1. TypeScript를 빠르게 JS로 변환 (esbuild 기반)

2. Node.js ESM 규칙에 따라 실제 실행

3. 모듈 경로 정합성 검증(특히 "moduleResolution": "bundler"와 궁합이 탁월함)
즉, 별도의 트랜스파일 빌드나 tsconfig-paths 등록 없이도 즉시 실행이 가능합니다.

 

🔷 Nodemon + tsx 조합(핫 리로드 개발 환경)

백엔드 API 서버를 개발할 때는 코드 변경 시 자동으로 서버가 재시작되면 매우 편리합니다.
이를 위해 가장 널리 사용되는 조합이 바로 Nodemon + tsx입니다.

 

1. Nodemon 설치

npm install -D nodemon

Nodemon 설치 화면
Nodemon 설치 화면

2. package.json 스크립트 설정

{
  "scripts": {
    "dev": "nodemon --watch src --exec tsx src/index.ts"
  }
}

#TypeScript 파일만 감시하고 싶으면
"dev": "nodemon --watch src --ext ts,tsx --exec tsx src/index.ts"

#특정 폴더를 제외하고 싶은 경우
"dev": "nodemon --watch src --ignore src/tmp --exec tsx src/index.ts"

▸ --watch src : src 폴더 전체에 대한 변경을 감시합니다.

▸ 파일 변경 감지 시 : Nodemon이 현재 실행 중인 프로세스를 종료

▸--exec tsx : 종료 후 tsx로 다시 index.ts 파일을 실행합니다.

 

3. nodemon 실행

npm run dev

 

실행 후 src/index.ts 또는 src/**/*.ts 파일을 수정하면 아래 화면과 같이 자동 재시작됩니다.

nodemon 실행 화면
nodemon 실행 화면

 

 

🔷 컴파일 없는 TS 실행 구조 이해 (Zero-Compile Architecture)

tsx가 제공하는 가장 강력한 기능은 “TS → JS 빌드 과정 없이 즉시 실행이 가능하다”는 점입니다.
이것은 다음과 같은 원리로 작동합니다:

 

1. esbuild 기반 TS 변환

tsx는 내부적으로 esbuild를 이용해 TS 코드를 메모리 상에서 빠르게 JS로 변환합니다.
디스크에 JS 파일을 생성하지 않기 때문에 극도로 빠른 속도를 보입니다.

▸ 별도의 dist 폴더 생성 없음
▸ tsc의 느린 emit 단계 없음
▸ I/O 비용 최소화
▸ 실시간 개발에 최적화

 

2. Node.js ESM 규칙에 매우 잘 맞춰진 구조

Node.js는 2023~2025 사이에 ESM을 강하게 밀고 있으며, CJS 지원을 축소하는 방향으로 정책이 정리되었습니다.

tsx는 이를 완벽히 지원하며

▸ import/export를 자연스럽게 처리
▸ 확장자 문제를 자동 해결
▸ CJS 패키지 import는 esModuleInterop과 함께 문제없이 작동

즉, 과거 ts-node나 ts-node/esm에서 자주 발생하던
“ESM import 오류”, “Cannot use import statement outside a module” 같은 에러를 겪을 일이 거의 없습니다.

 

🔷 ESM 기반 TS 프로젝트 운영 시 추천되는 관례

1. "type": "module" 선언 여부

ESM 기반 백엔드라면 package.json에 다음이 널리 사용되는 공식 관례입니다.

{
  "type": "module"
}

이 선언은 tsx에는 크게 영향을 주지 않지만, Node.js 실행과 테스팅 도구(Vitest)에서 ESM 모드 동작을 안정적으로 보장합니다.

 

2. tsx + tsconfig “bundler” 해석 방식의 궁합

tsconfig.json의 다음 설정은 tsx와 조합 시 최고 효율을 보입니다.

// tsconfig.json
// tsx 사용 시에는 "module": "ESNext" + "moduleResolution": "bundler"가 더 부드럽습니다.
"module": "ESNext",
"moduleResolution": "bundler",
"bundler"는
“브라우저 + 번들러(Vite/Webpack/tsup) + Node.js ESM 환경에서 공통적으로 사용하는 최신 경로 해석 방식”을
TypeScript에게 그대로 적용하는 옵션입니다.

 

이 방식은 최신 bundler 및 ESM 환경 기준 경로 해석 방식으로, 확장자 자동 보정, 조건부 exports 지원 등에서 매우 안정적입니다.

 

3. tsx는 테스트 러너(Vitest)와 자연스럽게 결합

최신 문서에서는 Vitest + tsx 조합을 강력 추천합니다.
테스트 실행 역시 TSX 기반이기 때문에 import/export 문제없이 동작합니다.

 

백엔드 TypeScript 실행 환경의 사실상 표준은 tsx입니다.

항목 ts-node tsx
ESM 안정성 낮음 매우 높음
실행 속도 느림 매우 빠름(esbuild)
빌드 필요 여부 emit 발생 빌드 없음
Node.js 공식 흐름과의 적합성 낮아짐 매우 높음
실무 개발자 경험(DX) 보통 최고 수준
핫 리로드 환경 가능하나 번거로움 Nodemon과 자연스럽게 통합

 

3. 테스트 환경 설정(Vitest 기반)

백엔드 서비스의 품질을 보장하기 위해 테스트 환경을 구축하는 것은 필수적입니다.

Node.js + TypeScript 프로젝트에서는 Vitest가 가장 널리 사용되는 테스트 러너입니다.

Vitest는 빠르고 가벼우며, TSX·ESM 환경과의 호환성이 매우 뛰어나 백엔드 실무에서 Jest를 대체하는 표준 도구로 자리 잡았습니다.

 

🔷 Vitest 설치

npm install -D vitest

Vitest 설치 결과 화면
Vitest 설치 결과 화면

선택적으로 coverage(코드 커버리지 보고서)가 필요하다면 아래 패키지도 함께 설치할 수 있습니다:

npm install -D @vitest/coverage-v8

참고: Vitest는 Node.js v18 이상 또는 v20 LTS 이상에서 최고의 성능을 발휘하도록 설계되었습니다.

 

🔷 tsconfig 설정 연동

Vitest 환경에서는 테스트 파일 내부에서 사용할 수 있는 전역 함수(describe, it, expect 등)를 TypeScript가 인식할 수 있도록 타입 선언을 연결해야 합니다.


tsconfig.json에 아래와 같이 추가해 주세요.

{
  "compilerOptions": {
    "types": ["node", "vitest/globals"]
  }
}

▸ TypeScript가 Node.js 전역 타입(fs, path, process 등)을 정상적으로 인식
▸ Vitest의 전역 테스트 함수(describe, it, expect)도 인식
▸ 개발 환경에서 Node + 테스트 타입이 모두 활성화됨

 

✔️ 주의사항

만약 프로젝트가 “테스트 파일만을 위한 타입 선언을 분리하고 싶다면” 다음처럼 tsconfig.test.json을 따로 생성하는 것도 좋은 방법입니다.

tsconfig.json
tsconfig.test.json

 

🔷 테스트 폴더 및 예제 작성

일반적으로 다음과 같은 구조를 권장합니다:

tests/
 └── sample.test.ts
import { describe, it, expect } from "vitest";

describe("sample test", () => {
  it("should add numbers", () => {
    expect(1 + 1).toBe(2);
  });
});

 

✔️ 백엔드 실무에서 자주 테스트하는 대상 예

▸ 서비스 로직 (Service Layer)
▸ 데이터베이스 쿼리/리포지토리
▸ 비즈니스 규칙 검증
▸ 외부 API 호출(mocking 포함)
▸ 예외 처리 흐름

▸ 유틸 함수

Vitest는 테스트 단위가 작을수록 더 빠르고 안정적으로 동작하며, 특히 mock 기능이 Jest와 유사하여 백엔드 로직 테스트에 매우 적합합니다.

 

🔷 테스트 실행

package.json에 다음 스크립트를 추가합니다.

{
  "scripts": {
    "test": "vitest"
  }
}

 

실행

npm test

vitest 실행 예시
vitest 실행 예시

 

✔️ 확장 스크립트(실무에서 자주 사용)

{
  "scripts": {
    "test": "vitest",
    "test:watch": "vitest --watch",
    "test:coverage": "vitest run --coverage"
  }
}

▸ "test": 테스트를 한 번만 실행하고 종료합니다.

▸ "test:watch": 파일이 변경될 때마다 테스트를 자동으로 재실행해주는 모드입니다.

▸ "test:coverage": 코드가 테스트에 의해 얼마나 실행되었는지를 분석(coverage)하여 보고서를 생성합니다.

 

✔ 마무리

설치 패키지 목록

typescript-examples@1.0.0 D:\NodejsDevelope\workspace\nodejs-tutorials
├── @eslint/js@9.39.1
├── @eslint/json@0.14.0
├── @types/node@24.10.1
├── eslint-config-prettier@10.1.8
├── eslint@9.39.1
├── globals@16.5.0
├── nodemon@3.1.11
├── prettier@3.6.2
├── tsx@4.21.0
├── typescript-eslint@8.46.4
├── typescript@5.9.3
└── vitest@4.0.14

 

package.json 예시

{
  "name": "typescript-examples",
  "version": "1.0.0",
  "type": "module",
  "main": "index.js",
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "dev": "nodemon --watch src --exec tsx src/index.ts",
    "test": "vitest",
    "test:watch": "vitest --watch",
    "test:coverage": "vitest run --coverage"
  },
  "lint-staged": {
    "*.{ts,js,jsx,tsx,json,md}": [
      "eslint --fix",
      "prettier --write"
    ]
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": "",
  "devDependencies": {
    "@eslint/js": "^9.39.1",
    "@eslint/json": "^0.14.0",
    "@types/node": "^24.10.1",
    "eslint": "^9.39.1",
    "eslint-config-prettier": "^10.1.8",
    "globals": "^16.5.0",
    "nodemon": "^3.1.11",
    "prettier": "^3.6.2",
    "tsx": "^4.21.0",
    "typescript": "^5.9.3",
    "typescript-eslint": "^8.46.4",
    "vitest": "^4.0.14"
  }
}

 

tsconfig.json 예시

{
  // 📌 TypeScript 5.9 기준 tsconfig 템플릿
  // 백엔드(Node.js ESM) 환경에 맞추어 정리한 설정입니다.

  "compilerOptions": {
    // ------------------------------------------------------------
    // 📁 File Layout
    // 프로젝트의 소스 경로와 빌드 출력 경로를 명확히 하고 싶을 때 사용합니다.
    // 백엔드 서비스는 일반적으로 src → dist 구조를 사용합니다.
    // ------------------------------------------------------------
    "rootDir": "./src",
    "outDir": "./dist",

    // ------------------------------------------------------------
    // 🧭 Path Alias 설정 (실무 필수 강력 추천)
    // ------------------------------------------------------------
    // baseUrl: TS가 import 경로를 해석할 기준 루트
    //   ✔ src를 기준 경로로 사용
    //"baseUrl": "src",
    //"paths": {
    // 예: @app/server → src/app/server.ts
    //"@app/*": ["app/*"],
    // 예: @config/env → src/config/env.ts
    //"@config/*": ["config/*"],
    // 예: @utils/logger → src/utils/logger.ts
    //"@utils/*": ["utils/*"],
    // 예: @services/user.service → src/services/user.service.ts
    //"@services/*": ["services/*"]
    //},

    // ------------------------------------------------------------
    // 🌐 Environment Settings (환경 설정)
    // module: Node.js의 ESM/CJS 해석 규칙을 그대로 따르는 설정입니다.
    //  - nodenext: Node.js 20+의 ESM 처리 방식을 TS가 따라가게 함
    //  - 백엔드에서 Node 런타임 호환성이 매우 중요할 때 적합
    // moduleResolution: import 경로를 어떻게 해석할지 결정
    //  - bundler : Vite / tsx / tsup 같은 빌드 툴 규칙 (확장자 생략 OK)
    // ------------------------------------------------------------
    // 순수 Node.js 백엔드 서비스, 서버/마이크로서비스
    //"module": "nodenext",
    //"moduleResolution": "nodenext",

    // tsx 사용 시에는 "module": "ESNext" + "moduleResolution": "bundler"가 더 부드럽습니다.
    "module": "ESNext",
    "moduleResolution": "bundler",

    // target: 출력되는 JS 문법 수준 (Node 18~20은 ES2022 이상 권장)
    // esnext는 최신 JS 문법을 그대로 사용
    "target": "ES2022",

    // lib: Node.js 환경에서 필요한 전역 기능 제공 (fetch 등 포함)
    //      어떤 JavaScript 표준/전역 기능을 사용할지 결정
    "lib": ["ES2022"],

    // Node.js 환경에서는 @types/node가 필요합니다.
    // types 배열에 node를 명시하면 TS가 Node 전역 타입(fs, path 등)을 인식합니다.
    "types": ["node", "vitest/globals"],

    // ------------------------------------------------------------
    // 📦 Other Outputs (빌드 출력 옵션)
    // sourceMap: 디버깅 시 원본 TS 파일을 추적하기 위해 필요
    // declaration: 라이브러리 공개 목적이 아니면 선택적
    // 백엔드 서비스라면 d.ts가 꼭 필요하지는 않지만 유지해도 무방
    // ------------------------------------------------------------
    "sourceMap": true,
    "declaration": false, // 백엔드 서비스는 보통 d.ts 필요 없음
    "declarationMap": false,

    // ------------------------------------------------------------
    // 🔍 Stricter Typechecking Options (엄격한 타입 검사)
    // 서비스를 안정적으로 운영할 때 매우 유용합니다.
    // ------------------------------------------------------------

    // 배열/객체 인덱스 접근 시 undefined 가능성을 항상 포함
    // (코드는 길어지지만 안전성이 크게 올라감)
    // 이 옵션은 실무에서 거의 사용되지 않습니다.
    // "noUncheckedIndexedAccess": true,

    // 선택적 프로퍼티를 정확하게 구분
    // { a?: string } → 'a: undefined'와 'a 미존재'를 엄격히 구분
    "exactOptionalPropertyTypes": true,

    // ------------------------------------------------------------
    // 🎨 Style Options (스타일/코드 규칙)
    // 아래 옵션들은 추천되지만 필요에 따라 켜거나 끌 수 있습니다.
    // ------------------------------------------------------------
    // "noImplicitReturns": true,
    // "noImplicitOverride": true,
    // "noUnusedLocals": true,
    // "noUnusedParameters": true,
    // "noFallthroughCasesInSwitch": true,

    // ------------------------------------------------------------
    // 👍 Recommended Options (추천 옵션)
    // 백엔드 실무에서 거의 필수에 가까운 설정들입니다.
    // ------------------------------------------------------------

    // TS의 가장 엄격한 타입 검사 모드 활성화
    "strict": true,

    // 백엔드 환경에서는 JSX를 사용하지 않으므로 제거
    // "jsx": "react-jsx",

    // import/export 문법을 변환하지 않고 원본 그대로 유지
    // ESM 환경에서 문제를 예방하기 좋음
    // 그래서 “타입만 필요한 import”를 반드시 import type으로 표시하도록 요구합니다.
    "verbatimModuleSyntax": true,

    // 파일을 독립된 모듈로 간주하여 ESM 환경 오류를 예방
    "isolatedModules": true,

    // 사이드 이펙트를 일으키는 import를 엄격하게 검사
    "noUncheckedSideEffectImports": true,

    // TypeScript가 모듈을 감지하는 방식을 강제로 모듈로 설정
    "moduleDetection": "force",

    // 외부 라이브러리 타입 검사 스킵 (실무에서 속도 향상 + 안정적)
    "skipLibCheck": true
  },

  // ------------------------------------------------------------
  // 📌 include / exclude
  // 컴파일 대상과 제외할 파일/디렉토리를 명확히 설정
  // ------------------------------------------------------------
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

 

 = 관련글 =

Visual Studio Code 설치 방법 (Installer / Zip 포터블 모드)

 

Visual Studio Code 설치 방법 (Installer / Zip 포터블 모드)

Windows에서 Visual Studio Code(이하 VSCode)를 설치하는 방법에는 설치형(Installer)과 포터블(Portable) 모드(Zip 파일) 두 가지가 있습니다. 이 글에서는 각각의 설치 방법과 포터블 모드 설정, 폰트 설정 방

quadcube.tistory.com

 

VSCode에서 Node.js 포터블 다중 버전 관리하기

 

VSCode에서 Node.js 포터블 다중 버전 관리하기

VSCode에서 Node.js 포터블 다중 버전 관리하기 📚 목차1. Node.js 포터블 설치란?2. 여러 Node.js 버전 병행 설치와 관리3. VS Code에서 프로젝트별 Node.js 버전 자동 적용4. 포터블 Node.js 다중 버전 자동 전

quadcube.tistory.com

 

Node.js(v20.19) 개발환경 세팅: ESLint·Prettier·VSCode·CI까지

 

Node.js(v20.19) 개발환경 세팅: ESLint·Prettier·VSCode·CI까지

Node.js(v20.19) 개발환경 세팅: ESLint·Prettier·VSCode·CI까지 📚 목차1. 프로젝트 시작: init과 package-json 구조 이해2. 코드 품질의 기본: ESLint + Prettier 설치와 설정3. 개발 효율 극대화: VSCode 확장과 settings

quadcube.tistory.com

 

Node.js 개발자를 위한 Jupyter Notebook 활용: VS Code + Deno 핵심 정리

 

Node.js 개발자를 위한 Jupyter Notebook 활용: VS Code + Deno 핵심 정리

Jupyter Notebook은 오랫동안 Python 중심 생태계에서 사랑받아 왔지만, 이제는 JavaScript와 TypeScript 개발자에게도 훌륭한 인터랙티브 개발 도구가 되었습니다.VS Code와 Deno 런타임, 그리고 Jupyter 확장을

quadcube.tistory.com

 

VS Code + GitHub 환경 구축: 설치부터 원격 저장소 연결까지

 

VS Code + GitHub 환경 구축: 설치부터 원격 저장소 연결까지

VS Code + GitHub 환경 구축: 설치부터 원격 저장소 연결까지 📚 목차1. Git 설치 및 기본 환경 설정2. VS Code에서 Git 연동 준비하기3. GitHub 계정 연결 및 인증 방식 설정(OAuth, PAT, SSH)4. 프로젝트 업로드:

quadcube.tistory.com

 


※ 게시된 글 및 이미지 중 일부는 AI 도구의 도움을 받아 생성되거나 다듬어졌습니다.

반응형

 

반응형