doeunnkimm_.log

밑바닥부터 모듈 따라가보기 (with. React)

Sat, 03 May 2025 13:43:54 GMT

최근에 모듈 시스템에 대해 공부하게 되었는데요. 공부하다보니 내가 작성하는 이 모듈이 브라우저에서 로드되는 것을 당연하게 생각하고 마음껏 개발만 하고 있었던 것 같았어요.

이번 글에서는 모듈을 로드하고 트랜스파일하고 빌딩하고 브라우저에서 로드하는 과정 하나하나에 집중해 보려고 합니다.

구성하려는 환경

tsx 파일을 브라우저에서 실행

런타임 환경

프로그램을 실행할 수 있는 필수적인 환경을 제공 ex. Node.js, Deno, Bun

우선 런타임 환경이 필요합니다. 우리가 소스 코드를 작성하게 되면, 어떤어떤..〰️ 과정을 통해 브라우저에서 실행될텐데, 이 작업들이 런타임 환경에서 돌아가게 됩니다.

우리가 프로젝트에서 모듈을 활용했다면 경로도 처리해야할테고, tsx로 작성했다면 브라우저가 이해할 수 있는 js로 변환해야 하는 이런 처리들이 런타임 환경에서 이루어져야 합니다. 최종적으로 브라우저가 실행할 수 있는 파일로 만들어주는 것이라고 할 수 있겠습니다.

🤔 런타임 환경은 왜 특정 언어만을 지원하는걸까?

각 언어는 문법, 메모리 관리 방식 등 세부적인 동작 원리가 다름
그래서 최적화하는 방식도 다름
그래서 특정 언어에 필요한 자원 관리 방식에 맞게 설계

🤔 나는 왜 당연하게 Node.js를 설치했던 것인가?

일단 Node.js는 JavaScript 런타임 환경
JavaScript는 웹 브라우저 내에서 바로 실행될 수 있어서, 웹 애플리케이션을 만드는 데에 효율적
브라우저에서 실행되는 JavaScript를, 브라우저에 닿기 전에도 처리할 수 있게 하여 여러 작업을 가능하게 해주는 것이 런타임 환경
Deno, Bun과 같은 다른 런타임 환경도 있지만, 아직은 성숙도와 생태계로 인해 많은 프로젝트에서 Node.js를 채택 중

🥟 Bun! 좋다

개인적으로 Bun을 좋아한다.
자세한 구성에 대해서는 아직 못 알아봤지만, 단순 사용해봤을 때 경험이 무척 좋았다. 정말 빨랐다.
시간이 된다면 Bun에 대해 다루는 포스팅을 남겨볼까 한다.
다들 써보시라!

패키지 매니저

패키지: 파일이나 코드의 집합

패키지 매니저: 프로젝트에 필요한 패키지를 설치, 관리, 업데이트, 제거하는 도구

우리는 이미 작성되어 있는 코드를 활용해서 프로젝트 개발을 빠르게 하곤 하는데요, React 역시 외부 라이브러리로, 패키지 매니저를 통해 설치하고 관리해야 합니다.

패키지 매니저가 무슨 일을 하는지는 토스 기술 블로그에 잘 설명되어 있어 생략합니다!

package.json

프로젝트에 대한 정보를 관리하는 파이롤, 패키지 매니저가 이 파일을 참조하여 모듈을 설치하고 관리

런타임 환경에서 사용할 변환 도구 같은 것들을 패키지 매니저를 통해 설치해서 사용할 겁니다. 이때 패키지 매니저는 package.json을 통해 이 의존성을 버전과 함께 관리하게 됩니다. 물론 node_modules나 lock파일이 필요하지만 의존성 이야기니까 조금 생략해볼게요.

프로젝트에 package.json이 없어도 패키지 매니저는 알아서 package.json을 생성해서 관리하는 것을 확인할 수 있었어요.

🤔 패키지 매니저가 달라도 항상 package.json을 참조하던데, 누가 정한 표준 같은건가?

npm(Node Pacakge Manager)에서 표준화한 파일
npm이 처음 package.json 파일 형식을 정의했고, 이후 다른 패키지 매니저들도 이 표준을 따르며 사용 중
덕분에 라이브러리에서 사용 중인 패키지 매니저와 내 환경에서의 패키지 매니저가 달라도 문제 없이 의존성을 설치하고 관리 가능

React 설치 & 구성

https://react.dev/learn/add-react-to-an-existing-project

https://github.com/vitejs/vite/tree/main/packages/create-vite/template-react-ts

index.html

브라우저가 처음 로딩할 실제 HTML 문서를 하나 추가합니다. React는 JavaScript를 실행해서 이 HTML 문서 안에서 컴포넌트를 렌더링 하게 됩니다.

id="root" 하위로 리액트 컴포넌트를 렌더링하기 위해 DOM을 하나 추가했습니다.

🤔 그냥 body에 하면 안되나?

vite도 그렇고 body가 아니라 div#root에 리액트 컴포넌트를 렌더링 하는 편
body에는 새로운 portal이나 다른 전역 요소들이 들어갈 수 있음
그 안에 React가 관리하는 영역은 따로 두는 것

main.tsx

index.html에서 생성해두었던 div#root에 리액트 컴포넌트 루트를 만들고 간단하게 하나 렌더할 수 있도록 했어요.

import React from 'react';
import { createRoot } from 'react-dom/client';

createRoot(document.getElementById('root')!).render(hello react
);

우리는 이 코드가 실행된 결과를 브라우저에서 보기를 원합니다. 브라우저가 js를 실행하는 방법을 복기해봅시다.

브라우저는 HTML 파싱을 하기 시작합니다.
파싱 중 script 태그를 만나면 js를 로드하고 실행합니다.

즉, html 파일에서 우리가 방금 만든 main.tsx 파일을 만날 수 있게 해줘야 한다는 말인데요,

vite에서는 src="src/main.tsx"처럼 개발 환경 기준에서 좀 더 직관적으로 쓰고 있더라구요. 저도 이 방법을 차용하고 조금 처리를 더해보겠습니다.

// scripts/build.ts
import { build } from 'esbuild';
import fs from 'fs/promises';
import path from 'path';

const htmlPlugin = () => ({
  name: 'html-plugin',
  setup(build) {
    build.onEnd(async () => {
      const templatePath = path.resolve('index.html');
      let html = await fs.readFile(templatePath, 'utf8');
      html = html.replace('src="src/main.tsx"', 'src="main.js"');
      await fs.writeFile(path.resolve('dist/index.html'), html);
    });
  },
});

build({
  entryPoints: ['src/main.tsx'],
  bundle: true, // 여러 파일을 하나로 묶기 <- import된 다른 파일들을 모두 묶음
  outfile: 'dist/main.js',
  plugins: [htmlPlugin()],
  loader: {
    '.tsx': 'tsx',
  },
});

esbuild는 기본적으로 TypeScript와 JSX를 자동으로 트랜스파일링한다고 합니다. 다만, 타입 검사는 하지 않기 때문에 실패 시 빌드를 깨트리려면 별도의 타입 검사 도구를 추가로 사용해야 합니다.

번들링에 대해서는 entryPoints로 지정한 파일을 시작으로, 그 파일에서 import된 파일들을 모두 묶어 최적화된 하나의 출력 파일을 생성합니다.

추가로 htmlPlugin을 넣었어요. index.html에서 개발 환경 시 좀 더 직관적인 확인이 가능한 경로인 src="src/main.tsx"를 유지하고 빌드 시점에 이걸 replace한 후에 빌드하도록 했어요.

package.json에는 아래와 같은 필드를 추가해서 빌드할 수 있었습니다. build.ts 파일을 ESM으로 작성했기 때문에 ESM 방식으로 해석할 수 있도록 type 필드를 추가했습니다. 또, TypeScript로 작성된 build.ts 파일을 실행하기 위해 tsx 패키지를 설치하고 이를 통해 실행했습니다.

node scripts/build.ts    # ❌ 기본 Node.js는 .ts 파일 실행 불가
tsx scripts/build.ts     # ✅ 바로 실행 가능

{
  "type": "module",
  "scripts": {
    "build": "tsx scripts/build.ts"
  },
  "devDependencies": {
    "tsx": "^4.19.4"
  }
}

브라우저

여기까지 해서 dist 파일이 만들어졌네요. 이제 이 파일이 어떻게 브라우저에서 로드되어 우리가 보고 있는건지 살펴보려고 합니다.

우리가 프로젝트를 배포한다고 하면, 빌드된 결과물인 dist 폴더가 실제로 서버에 올라가게 됩니다. 사용자가 웹사이트에 접속하면, 서버는 가장 먼저 dist/index.html 파일을 응답하게 되죠!

이 HTML 문서는 브라우저에 의해 파싱되면서,

이렇게 되면 모든 파일이 window 변수에 등록이 되고, 순서가 잘못되면 런타임 에러가 발생할 수도 있었습니다. 이러한 문제를 해결하기 위해 런타임 환경에서는 AMD, RequireJS 같은 모듈 로더가 등장했다고 해요. 모듈 간의 의존성을 명시할 수 있도록 해서 순서를 관리할 수 있도록 하고 비동기로 로드할 수 있게도 했어요.

즉, 런타임 환경에서 비동기로 로드하기도 하고 모듈 로드 순서를 관리하는 방식을 활용합니다.

require(['foo', 'bar'], function(foo, bar) {
  foo();
  bar();
});

그런데 결국 위 방식도 개발자들이 모듈 의존성을 수동으로 관리해야했고, 불필요한 번들링이나 중복 로딩이 발생할 수 있었다고 해요.

✈️ ESM을 표준으로

ESM(ECMAScript Modules)는 ECMAScript 표준으로 JavaScript의 공식 모듈 시스템으로 설계되었어요. 비공식 모듈 시스템(ex. CJS, AMD 등) 방식들은 런타임 환경에서와 브라우저에서 모듈을 다르게 처리하는 문제가 있어 이를 동일한 방식으로 처리할 수 있는 표준화된 방법이 필요했다고 합니다.

ESM이 도입되면서 브라우저와 Node.js를 포함한 모든 자바스크립트 환경에서 사용할 수 있는 공식적인 방법이 되었답니다.

🤔 패키지에서 ESM으로 모듈을 정의했는데, 구 버전 브라우저라면?

배민 기술 블로그 - Vite로 구버전 브라우저 지원하기

구 버전 브라우저에서는 ESM을 지원하지 않을 수 있겠습니다. ES6에서 처음 도입되어 ESM을 사용할 수 없는 경우가 생길 수 있는데요,

트랜스파일러를 이용하여 팀에서 지원하고자 하는 범위에서 실행될 수 있도록 트랜스파일링하여 구형 브라우저에서도 사용할 수 있도록 해야 합니다.

🪴 ESM은 기존에 어떤 문제를 해결했을까?

표준화된 모듈 시스템을 제공하여 다양한 시스템 간의 호환성 문제를 해결
비동기적이고 효율적인 모듈 로딩을 통해 초기 로딩 속도와 성능 최적화
정적 분석과 최적화가 가능하여, 더 작은 번들을 생성하고 불필요한 코드를 제거
모듈 의존성 관리의 명확성 제공으로 충돌이나 잘못된 순서 문제를 해결
import, export 키워드로 개발자 경험 개선을 통해 모듈 시스템을 더 쉽게 이해하고 사용할 수 있게 함

ESM-only

Move on to ESM-only

라이브러리에서는 이러한 이유로 CJS, ESM을 같이 지원하곤 하는데요, 점점 더 많은 라이브러들이 ESM 전용으로 전환을 고려하거나 이미 그렇게 하고 있다고 합니다.

CJS와 ESM은 근본적으로 다른 모듈 시스템으로, 상호 운용할 경우 까다로운 문제로 이어지는 경우가 여전히 많다고 하네요. 또, 라이브러리에서 두 포멧을 지원한다는 것을 패키지의 크기를 2배가 되는 것이죠.

🫢 Node.js에서 require로 esm 모듈을 로드할 수 있는 기능을 제공한다고 해요

https://socket.dev/blog/require-esm-backported-to-node-js-20

Node.js에서 require로 ESM을 로드할 수 있도록 지원한다는 것은 혼합 사용을 권장한다는 의미보다는 듀얼 포맷의 지원을 줄이고, ESM으로 통일해 나가려는 호환성 조치로 보여요.

장기적으로는 새로운 모듈은 ESM으로만 작성되고, 점차 CJS를 줄이려는 방향으로 보이기도 했습니다.

🧐 생태계의 움직임을 따라야 우리도 움직여야 이유

기술의 지속 가능성

생태계가 이동하는 방향은 기술적 한계를 극복다고 효율을 높이기 위한 집단의 선택인 것인데요, 예를 들어 ESM으로의 전환은 정적 분석 최적화 트리 쉐이킹 등의 필요에서 비롯된 것처럼요.

생태계에서 사용되지 않거나 구식이 되어버린 기술을 고수하면, 언젠가 지원이 끊기고, 보안 업데이트도 안 되며, 관련 자료도 점점 사라지게 됩니다.

반면 생태계가 움직이는 방향을 따르면 그에 맞춰 새로운 도구와 커뮤니티도 그 방향으로 발전된다는 말이며, 이와 방향이 같아야 그에 맞춰 시스템을 계속 지속할 가능성이 커진다는 것이겠죠?

😰 프로젝트에서 node 버전을 올리기 전에 고려해야하는 것?

프로젝트에서 사용 중인 패키지들이 새로운 node 버전과 호환되는지 확인해야 합니다. 저도 회사에서 레거시 프로젝트의 스토리북을 열어 봐야할 일이 있었는데, node v18로 전환해야만 스토리북이 실행되더라구요 🤔

이처럼 node 버전을 올렸을 때 사용 중인 라이브러리나 배포 환경에 문제가 없는지 테스트하고 문제가 생겼다면 의존하고 있는 것들의 버전을 함께 업데이트해야 하는 큰 작업이 될 수 있을 것 같네요.

너무 당연하게 런타임 환경, 패키지 매니저, 스캐폴딩을 사용하기만 했던 것 같았는데요, 이번 글을 통해 하나씩 필요한 걸 찾아가면서 그 도구들의 필요를 느끼고 당연하게 생각했던 것들에 대한 의문을 풀었던 것 같아요.

물론 빌드 설정은 당장 필요한 필드만 추가하여 더 정교한 최적화가 필요하다면 더 많은 설정들이 필요하겠지만, 모듈이 어떻게 인식될 것인가에 집중해보면 원하는 설정을 골라서 쓸 수 있을 것 같아요. 🏃

Reference

플러그인으로 DX 개선하기 with Webpack

Sat, 30 Nov 2024 07:51:55 GMT

최근에 플러그인을 통해서 DX를 개선한 경험이 있어 이를 공유해보려고 합니다. 방법이 번뜩 생각이 났고, 비교적 간단한 작업이 후딱 반영했는데요. 이번 글에서 경험을 공유하고, 또 저도 더 자세히 알아보려고 합니다. 🚀

어떤 상황?

.md 파일들을 이관해야 하는 작업이 필요했어요. 문서화를 위해 사용하고 있는 도구는 다행히도 md → mdx로 변환하는 기능이 내장되어 있긴 하더라구요.

그런데, MDX는 Markdown과 JSX(JavaScript XML)를 결합한 포맷으로, Syntax 오류가 발생할 수 있습니다. 예를 들면 JSX 태그가 제대로 닫히지 않았다는 이유로 말이죠.

그래서 아래와 같은 상황이 다릅니다.

// md: ✅ no problem
이 문장은 줄바꿈을 
 태그로 표현합니다.

// mdx: 🚨 error
이 문장은 줄바꿈을 
 태그로 표현합니다.

이미 작성되어 있는 많은 파일들에서 혹은 이 이곳저곳에서 사용되고 있었어요. 그래서 아래와 같은 에러를 마주했습니다.

정리해보자면 상황은 이렇습니다.

md 파일을 이관해옵니다.
사용하고 있는 도구가 알아서 md → mdx로 바꿔줍니다.
그런데 md에서 사용하고 있던 문법들이 mdx에 와서 터지고 있습니다.

일차원적인 해결 방법

위 문제를 해결하기 위해서는 아주 일차원적인 방법이 생각나기도 했어요.

손수 수정하기 (ㅋㅋ)
파일을 돌면서 일괄적으로 바꿔주는 script 추가하기
앞으로는 이런 일을 방지하기 위해 mdx 문법을 지키기

위 방법들은 비용이 조금씩 반복적으로 발생할 것 같았어요. 왜나면, 앞으로 문서를 같이 작성하게 될 사람들은 MD에 이미 익숙하기 때문에, 앞으로도 동일하게 문서를 작성할 경우 2번도 반복해야 하며, 3번도 생산성을 저하시키는 요인이 될 것 같았습니다.

저는 이렇게 해결했어요

제가 원하는 건 이렇습니다.

MD에 익숙한 사람들도 그대로 사용할 수 있는 환경. 즉, 신경 안 쓸 수 있는 환경

이러한 환경 차이를 중간에서 처리해주는 방식을 사용하면 어떨까 생각이 들었어요. 기존 MD 파일을 별도의 수정 없이 MDX 환경에서 사용할 수 있도록 만들어줄 수 있지 않을까 했습니다.

플러그인 추가

우선 발견한 문제는 이 문제였어서, 이를 transform하는 과정을 추가하면 될 거라고 생각했어요.

그래서 제가 선택한 방법은, 플러그인을 추가하는 것이에요.

사용하고 있는 문서화 도구는 Next.js 기반이기 때문에 next.config.js에 webpack config를 쉽게 추가할 수 있었습니다. (Next.js는 기본적으로 Webpack을 통해 번들링)

// lib/replaceBr.js
const replaceBr = async() => {
  const { default: visit } = await import('unist-util-visit');

  return (tree) => {
    visit(tree, 'html', (node) => {
      node.value = node.value.replace(//gi, '
');
    });
  };
}

module.exports = replaceBr;

// next.config.js
const replaceBr = require('./lib/replaceBr');

const nextConfig = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.md$/,
      use: [
        {
          loader: 'remark-loader',
          options: {
            remarkOptions: {
              plugins: [replaceBr],
            },
          },
        },
      ],
    });
    return config;
  },
}
module.exports = nextConfig

MD 파일을 Remark를 사용해 파싱을 하고, 제가 추가한 플러그인이 적용될 수 있도록 설정했어요.

결과적으로 아래와 같이 이전과는 다르게 빌드에 문제없이 성공할 수 있었어요.

최근 회사에서 플러그인을 추가해서 어떤 문제를 해결했다고 들었던 것을 출발로, 번뜩 생각이 났던 것이였어요. 아이디어와 gpt만으로 코드를 작성하여 빠르게 반영할 수 있었지만, 더 깊은 내용을 이해하기 위해 추가적으로 알아보려고 합니다.

Webpack

Webapck은 번들러입니다. 번들러는 모듈과 리소스를 번들로 묶어 효율적으로 관리하고 최적화하는 역할을 해요.

번들링 과정

번들링(bundling)이라는 건, 여러 개의 모듈, 리소스들을 하나 또는 여러 개의 출력 파일로 묶는 과정입니다. 주로 JavaScript, CSS, 이미지와 같은 각종 리소스들을 묶어서 효율적으로 배포할 수 있도록 최적화하는 작업입니다.

🤔 효율적 배포라는 건 뭘까?

배포되어야 하는 파일들의 크기가 클수록 이를 다운로드하고 실행하는 데 더 많은 시간이 소요됩니다. 번들러가 수행하는 효율적인 배포를 위한 작업들에는 즉, 번들링 하는 과정에서 수행하는 작업에는 아래와 같은 것들이 있어요.

번들링: 여러 개의 작은 파일을 하나로 합쳐 네트워크 요청수 절약
파일 크기 최적화: 불필요한 공백, 주석, 줄바꿈 등을 제거하여 파일 크기 최소화 → 압축하여 다운로드 속도 개선 및 네트워크 대역폭 절약
코드 스플리팅: 여러 개의 작은 번들로 분할되어, 필요한 코드만 로드할 수 있도록 → 초기 로딩 시간 단축
이미지 최적화: 이미지 파일을 압축하거나, 포맷을 변경하여 파일 크기 절약 가능. 이미지 최적화 플러그인(ex. image-webpack-loader, url-loader)을 사용하여 압축 및 파일 크기 절약 가능
Tree Shaking: 사용되지 않는 코드를 제거 → 모듈 시스템을 분석하여 실제로 사용되지 않는 코드를 제거하여 번들 크기 절약

위와 같은 작업을 거쳐서 번들 파일을 생성하는 것인데, 하나씩 자세히 알아보려고 합니다.

번들링: 적당한 번들링을 위한 전략

🤔 적당히 번들링한다는 건 뭘까?

너무 많이 쪼개거나 너무 많이 묶는 것은 모두 성능에 부정적인 영향을 줄 것 같아요. 추상적이지만.. 적당히 번들링하는 전략이 필요할 것 같았습니다.

보통 적절한 번들링을 위한 전략에는 다음과 같은 것들이 있어요.

⚔️ 코드 스플리팅

https://webpack.js.org/guides/code-splitting/

엔트리 포인트에서부터 모듈을 탐색하여 의존성을 파악하고, 필요한 모듈을 추적해서 번들로 묶습니다. 예를 들어 A.js에서 B.js와 C.js를 import해서 사용한다면, 번들에 포함되도록 추가하고 각각의 모듈들을 하나의 번들 파일 또는 여러 개의 파일로 묶어서 최종 결과물을 만들어요.

📦 모듈 공유하기

dependOn이라는 옵션을 통해 청크 간 모듈을 공유할 수도 있다고 합니다. 중복을 줄이기 위해 모듈을 공유하도록 하는 것인데요.

const path = require('path');

module.exports = {
  mode: 'development',
  entry: {
    index: {
      import: './src/index.js',  // 'index' 엔트리 포인트
      dependOn: 'shared',        // 'shared' 모듈에 의존
    },
    another: {
      import: './src/another-module.js',  // 'another' 엔트리 포인트
      dependOn: 'shared',        // 'shared' 모듈에 의존
    },
    shared: 'lodash',  // 'shared'는 'lodash' 라이브러리로 지정
  },
  output: {
    filename: '[name].bundle.js',  // 번들 파일 이름은 엔트리 포인트 이름을 따름
    path: path.resolve(__dirname, 'dist'),  // 결과물은 'dist' 폴더에 저장
  },
};

위와 같이 shared로 lodash를 공유하도록 설정할 수 있어요. index와 another 모두 lodash를 의존하고 있기 때문에 Webpack은 이를 별도의 번들로 추출하고 중복을 피합니다. lodash는 shared.bundle.js라는 별도의 파일로 추출되고 이를 참조하는 형태로 구성되게 됩니다.

라이브러리를 명시한다고 해서 라이브러리 전체 모듈이 번들되는 것은 아니고, 트리 쉐이킹에 의해 사용되지 않는 부분은 제거되고 공통 코드만 포함된다고 합니다. 그럼 lodash 같이 CJS 모듈 시스템을 지원하는 라이브러리 즉 트리 쉐이킹이 어려운 라이브러리는 전체가 번들에 포함되게 되는 것이겠네요.

🌪️ dymamic import

필요한 시점에만 모듈을 로드할 수 있도록 번들을 분리하는 기법을 말합니다. 엔트리 파일에서 사용은 되지만, 초기 렌더링 시에는 실질적으로 사용되지 않는다면, dynamic import 번들로 분리하여 초기 렌더링 속도를 개선할 수 있습니다. 즉, 당장 필요하지 않으니까 나중에 로드할게 같은 것이죠.

주의할 점도 있을 것 같아요. 아무래도 동적 임포트는 모듈을 분리하는 것이므로 네트워크 요청이 늘어납니다. 너무 많은 사용은 오히려 네트워크 응답 시간을 느려지게 하여 사용자가 기다려야 하는 상황이 일어날 수 있음을 주의해야겠습니다.

최적화: 최적화는 어떻게?

https://webpack.js.org/configuration/optimization/

Webpack에서 소개하고 있는 최적화 전략이 정말 많더라구요.

이 중에서 제가 흥미로웠던 최적화 기법들 몇 가지를 소개해보려고 합니다.

🗽 chunkIds

생성되는 청크의 이름을 결정하는 설정
기본적으로는 파일 일므에 해당하는 고유 식별자(숫자, 해시 값, ...)를 가진다
named로 설정할 경우, 명시적인 이름을 할당 → 디버깅 시 용이
deterministic으로 설정할 경우, 빌드마다 동일한 ID 할당 가능 → 캐시 관리가 중요하거나 디버깅 환경에서 예측 가능하도록 설정하고 싶을 때 사용

👝 minimize, minimizer

코드 압축을 담당하는 설정
자동으로 코드 최소화를 할지 여부를 결정 (기본값 true) → TerserPlugin(기본 플러그인)을 사용해 JavaScript 파일을 최소화
minimizer에는 최소화할 때 사용할 플러그인 설정 가능
디버깅 용도로 false로 설정하여 분석 활용

❄️ sideEffects

Webpack은 트리 쉐이킹을 통해 사용되지 않는 코드를 제거하는데
일부 모듈은 side effect를 가질 수 있기 때문에, 모듈을 제거하지 않도록 설정 가능
true로 설정할 경우, side effect를 가질 수 있는 코드를 트리쉐이킹 하지 않음으로써 보호
package.json에서도 sideEffects 필드를 통해 설정 가능

Webpack이 판단하는 side effect가 없는 코드는 즉, 순순히 트리 쉐이킹을 해주는 코드는 순수 함수만 포함된 모듈이나 상태를 변경하지 않는 모듈이라고 해요. (빡빡함) 그래서 판단하에 직접적으로 설정을 해주면 번들 크기 면에서 이점을 얻을 수 있어 보입니다.

🎄 Tree Shaking: 오해와 진실

트리 쉐이킹은 정적 분석을 통해 사용되지 않는 부분을 찾아서 제거한다는 간단한 원리에 대한 코멘트를 남기고..

이번에는 트리 쉐이킹에 대한 오해와 진실에 대해 정리해보려고해요. 최근 회사에서 트리 쉐이킹 관련해서 작업이 있었는데 헷갈리더라구요. 🤔 ㄷ..되는건가?

1️⃣ export ... = Object.assign(...) → ❌

서브 컴포넌트를 제공하기 위해 Object.assingn를 통해 통합해서 제공하기도 하는데요.

export const Foo = Object.assign(FooImpl, {
  A: FooAComponent,
  B: FooBComponent,
  C: FooCComponent,
})

Object.assign 함수는 런타임에 객체를 생성합니다. 따라서 정적 분석 시점에서는 프로퍼티에 담은 모듈을 다 포함하게 됩니다.

실제로 해봤어요.

빌드된 결과는 아래와 같이 Object.assign이 그대로 담기면서 모든 프로퍼티를 포함하고 있었습니다.

2️⃣ export * as Foo from 'Foo' → ⭕️ (최신)

아래와 같은 케이스는 어떨까요?

// Foo.tsx
import { FooA } from 'FooA'
import { FooB } from 'FooB'
import { FooC } from 'FooC'

export { FooA as A }
export { FooB as B }
export { FooC as C }

// index.ts
export * as Foo from 'Foo'

위와 같은 구조는 개별적으로 export하고, index.ts 에서 Foo.tsx에서 export된 모든 내용을 Foo라는 네임스페이스로 다시 export하고 있는 구조에요. 사용처에서는 아래와 같이 쓸 수 있어요.

import { Foo } from 'lib-foo'

여러 모듈을 하나의 네임스페이스로 묶은 방식으로, 각 모듈은 독립적인 모듈로 처리됩니다. 따라서 정적 분석이 가능하여 트리 쉐이킹이 가능합니다.

찾아보니, webpack4 이전에는 불가능했다고 해요. 정확하게 이제는 됩니다!라는 포스팅을 못찾아서..직접 해보았습니다. 결과는 아래와 같아요.

아래는 결과입니다.

트리 쉐이킹이 된 것을 확인할 수 있었습니다 👍🏽

3️⃣ import * as React from 'react' → ⭕️

이 또한 네임스페이스로 불러오는 방식으로, 각 모듈을 독립적인 모듈로 처리가 가능하기 때문에 트리 쉐이킹에 문제가 없습니다. (관련 포스팅)

plugin의 동작 원리

Webpack에서 플러그인은 빌드 프로세스를 확장하거나 커스터마이징하는 데 사용되는 도구에요. 플러그인은 특정 작업을 수행하는데, 주로 빌드 최적화, 번들링, 코드 스플리팅, 파일 시스템 조작 등을 처리할 수 있습니다.

그래서 플러그인이 실행되는 시점을 설정할 수도 있고, 이를 통해 특정 시점에 원하는 작업을 추가할 수도 있습니다.

Webpack이 처리할 수 있도록 로더를 통해 JS 모듈로 변환해서 처리합니다. Webpack은 JS 파일만 처리할 수 있기 때문에 css-loader나 style-loader 와 같은 로더를 통해 변환을 하는 것이죠.

끝으로

우연한 기회로 플러그인을 통해 DX를 개선한 경험이 생겨서 공유하게 되었는데요! 하다보니 Webpack의 전반적인 내용까지 공부하게 되었습니다 😁

이 경험을 통해, 그동안 코드에서 에러가 발생하면 그냥 맞춰서 돌아가게 만드는 것에서 벗어나, 이제는 필요할 때 빌드 프로세스를 활용해 변환을 통해 문제를 해결할 수 있다는 자신감이 조금.. 생긴 것 같았다는 말을 남기고 글을 마무리해보려고 합니다 :hooray: ! 👋

작고 소중한 디자인 시스템을 NPM 배포해보자

Thu, 19 Sep 2024 16:51:48 GMT

@sambad/sds

아직 부족한 게 정말 너무 매우 엄청나게 많지만, 작게나마 디자인 시스템 구축을 했었어요.

최근에 개인적으로 의존성 관련 공부를 하다보니 package.json와 빌드 시 신경 써줄 수 있는 부분이 생각보다 세세하고 재밌더라구요.

그래서 디자인 시스템 패키지을 가지고 직접 처음 해보려고 합니다. 이 과정에서 NPM 배포를 위해 고려하고 설정한 내용들을 함께 남겨보려고 합니다.

제가 개발하고 있는 환경은 다음과 같아요.

"turbo": "^2.0.4"
"react": "^18"
"typescript": "^5"
"@emotion/react": "^11"

터보레포를 사용하고 있고, 내부에 존재하는 @sambad/sds 라는 패키지를 배포하려고 해요.

Bundler를 골라보자, vite ⚡️

🤔 뭘로 하지?

우선 @sambad/sds 패키지는 단순히 UI 관련 모듈들을 모아둘 목적으로 생성된 단순 패키지로 번들러는 없었어요. 그래서 번들러를 선택해야 했습니다.

제가 후보로 고민했던 번들러들은 다음과 같아요.

저는 프로덕션 빌드 시에만 번들러가 필요해서, 프로덕션 빌드타임만을 비교해보려고 합니다.

🤖 turbopack

Why Turbopack?

incremental computation → 변경 사항을 효율적으로 처리하여 재구축 시간을 줄이고 개발 생산성을 향상
모든 함수의 결과를 캐싱 → 동일한 작업을 두 번 수행할 필요 X
현재는 Next.js에서만 사용 가능
- 개발 서버에만 내장
- Next.js도 프로덕션 빌드 시에는 Webpack 사용

⚡️ vite

https://vitejs.dev/

Esbuild(개발 모드) + Rollup(프로덕션 빌드)
- Esbuild가 현재 어떤 번들링 툴 보다 가장 빠른 성능을 자랑하지만
- 아쉬운 생태계와 브라우저용 번들링에서 아직은 다른 툴보다 안정성이 떨어진다는 평가가 있어
- 프로덕션 빌드 시에는 안정성과 생태계가 비교적 더 큰 Rollup을 선택
Typescript 는 Esbuild 를 사용
- tsc 대비 20~30배 빠른 퍼포먼스
es2015 이상만을 지원
- 그 이하도 지원하고 싶다면 @vitejs/plugin-legacy 사용해서 가능
라이브러리 모드 지원
- build 의 lib 옵션과, rollupOptions 으로 빌드시에 번들링에서 제외할 라이브러리 등 여러 설정을 쉽게 가능
- TS로 작성한다면 vite-plugin-dts 플러그인을 추가하여 모듈마다 .d.ts 파일 자동 생성 가능

🤚 vite로 결정했어요

사실 turbopack이 아직은 범용적으로 사용할 수는 없어, 자연스레 vite가 되긴 했습니다.

제가 직접 벤치마크를 측정해보진 않았지만, 해당 포스팅을 참고했을 때 모든 부분에서 vite > turbopack 이였습니다.

Webpack을 비교 대상에서 제외했던 이유는, 필수적으로 해아하는 보일러플레이트 량이 꽤 된다는 것이 가장 큰 이유였습니다. 또, 위 벤치마크 표에서도 알 수 있듯 Webpack의 성능은 vite와 비교했을 때 약 10배 정도의 차이가 있었습니다.

vite 시작하기

vite를 install하고 package.json에 build script만 추가한 후, 기본적인 config만 추가하면 기본적인 build는 실행됩니다.

// vite.config.ts
import { defineConfig } from 'vite';
import { resolve } from 'path';

export default defineConfig({
  build: {
    lib: {
      entry: resolve(__dirname, 'src/index.ts'),
      name: 'index',
      fileName: 'index',
    },
    outDir: 'dist',
  },
});

peerDependencies

최근에 어떤 자리에서 peerDependencies에 대해 아주 잠깐 언급되었어서, 알아봐야겠다~ 했었는데 번들 사이즈를 위해 중요한 역할을 하는 package.json 의 필드여서 이번 글에도 포함하게 되었어요.

간단하게 개념을 살펴보고 제가 어떻게 적용을 했는지 남겨보려고 합니다.

🤔 peerDependencies?

특정 패키지가 다른 패키지의 특정 버전이 설치되어 있어야 함을 명시하는 데 사용
예를 들어, React 관련 라이브러리에서 react와 react-dom을 peerDependencies로 지정하면, 이 라이브러리를 사용하는 프로젝트에서 반드시 해당 버전의 React가 설치되어 있어야 함을 의미

🥸 무엇을 위해 필요한걸까?

호환성 보장

특정 라이브러리와 함께 사용될 다른 라이브러리의 버전을 명시하여, 충돌이나 호환성 문제를 방지

💡 보통은 여러 개를 허용해주거나, 특정 버전 이상으로 명시해주어 폭넓게 허용

아래는 대표적인 디자인 시스템 패키지들의 package.json 내 peerDependencies 필드예요.

그래서 peerDependencies는 사용처 버전에 따라 갈 수 있도록 통합 패키지에서는 devDependencies로 사용하거나 개별 패키지를 제공하는 경우(모노레포를 사용) 번들에 포함되지 않도록 하여 사용합니다.

🤨 peerDepencies에 설정해주고, dependencies에서 제거해주었다

저는 모노레포를 사용하고 있어서, 아래와 같이 명시해주었어요.

// as-is
"dependencies": {
  "@emotion/react": ">=11",
  "react": ">=18",
  "react-dom": ">=18"
},

// to-be
"peerDependencies": {
  "@emotion/react": ">=11",
  "react": ">=18",
  "react-dom": ">=18"
},

이제 해당 패키지에서 해당 패키지들을 번들에 포함하지 않고, 사용처에서 설치된 버전에 맞게 사용되는 것을 상상했기 때문에 dependencies 필드에서는 제거해주었어요.

번들에서도 제외하기

위와 같이 package.json을 구성하고 build를 하게되면 제외될 거라고 생각했습니다. 🤔 dependencies에 명시 안 했으니까 포함 안 되지 않을까? 했는데 포함되었습니다.

이미 코드 곳곳에는 peer로 넣어둔 라이브러리를 사용하고 있긴 하므로 번들에 포함되었던 것입니다.

그렇지만, 저는 이걸 바란 게 아니였어요.

이 라이브러리에서는 이 번들을 포함하지 않고, 사용처에서 이미 사용하고 있는 버전의 패키지와는 다르게 중복되어 들어가지 않는 것과 사용처에서의 패키지가 사용되기를 원했습니다(제가 peer로 설정한 버전과 호환이 되어야겠지만요). peer로 추가한 이유도 마찬가지였습니다.

🥳 vite로 쉽게 제외하기

vite.config.ts파일로 아주 쉽게 번들에서 제외할 수 있었어요.

import { defineConfig } from 'vite';
import { resolve } from 'path';

export default defineConfig({
  build: {
    rollupOptions: {
      external: ['react', 'react-dom', '@emotion/react'], // 번들 포함 X
    },
    ...
  },
});

번들에서 제외하고 번들 사이즈를 약 81.2%나 줄일 수 있었어요.

as-is	to-be
186.52kB	34.77kB

ESM, CJS

이런 경험이 처음이다보니, 많은 레퍼런스들을 보게 되었었어요. 보다보면, package.json에 이런 필드들이 있었어요.

"type": "module",
"main": "dist/cjs/index.cjs",
"module": "dist/esm/index.js",

ESM과 CJS에 대해서도 지식이 얕아서 관련되어 알아보고, 어떻게 적용했는지도 기록해보려고 합니다.

🤔 둘은 뭐길래?

ESM과 CJS는 자바스크립트 모듈 시스템입니다.

모듈 시스템에서의 모듈은 프로그램을 구성하는 시스템을 기능 단위로 독립적인 부분으로 분리한 것을 의미합니다.

모듈 시스템은 모듈을 정의하고, 가져오고, 관리하는 규칙과 방법을 제공합니다. 자바스크립트에서는 ESM(ECMAScript Modules)와 CJS(CommonJS) 두 가지 주요 모듈 시스템이 있는 것이죠!

🤨 ESM(ECMAScript Modules)

import와 export 키워드를 사용
비동기 로딩: 모듈을 비동기적으로 로드 가능
정적 분석: 코드가 실행되기 전에 의존성 분석 가능 → Tree-shaking 쉽게 가능
정적인 구조로 모듈끼리 의존하도록 강제 → 불러온 값 수정 X

😑 CJS(CommonJS)

require()와 module.exports` 사용
동기 로딩: 모듈을 동기적으로 로드
require/module.exports를 동적으로 하는 것에 제약 X = 불러온 모듈 수정 가능
- 그래서 런타임에 동적으로 로드되고 수정될 수 있기 때문에, 코드가 실행되기 전에는 어떤 모듈이 어떤 의존성을 가질지 예측하기 어려움
- 특정 조건에 따라 모듈을 다르게 로드하거나 수정하는 경우, 빌드 도구는 이러한 동적 관계를 분석 X

🥸 라이브러리 관점에서 둘 다 지원해야 하는건가?

Node.js 12부터 ESM라는 새로운 모듈 시스템이 추가가 된 것
그래서, 이미 많은 프로젝트에서 CJS 사용하고 있을 것
둘 다 지원하면, 사용처의 필요에 따라 하나를 선택 가능 → 유연성 증가

🙂 package.json에서 type, main, module 필드

type: "module" | "commonjs"
- 모듈의 유형을 지정. 기본적으로 어떤 모듈 시스템으로 처리될지를 결정
- 정의되어 있지 않다면 "commonjs"로 처리
main
- 패키지를 불러올 때 기본적으로 사용할 진입점 파일을 지정
module
- main 필드와 유사한 목적으로 사용되는 필드
- ESM 환경에서 패키지를 사용할 때 진입되는 경로

🤔 아무 생각없이 ESM으로 개발한 것 같은데..뭐지?

최신 스캐폴딩 도구를 사용하면, package.json에서 type 필드를 module로 설정해주기 때문인데요.

type 필드 값에 따라 .js가 어떻게 처리될지가 결정됩니다.

"module"이면, ESM으로 처리
"commonjs"이면, CJS로 처리

아니면, 직접적으로 확장자명을 입력하여 처리되도록 하는 방법도 있습니다.

.mjs: ESM 파일로 인식
.cjs: CJS 파일로 인식

그래서 JS 파일이 CJS인지 ESM인지 확인하려면 파일 확장자, package.json의 type 필드, 사용된 모듈 구문을 확인하면 됩니다.

type 필드를 설정했더니 타입 에러 ?

이제 위애서 알아본대로 프로젝트가 ESM으로 동작할 수 있도록 "type": "module"을 명시해주었습니다.

"type": "module"

그랬더니 아래와 같이 갑자기 와장창 타입 에러가 발생했습니다.

이렇게 설정한 순간부터는 import/export 문이 ESM 규칙을 따라야합니다. 이 규칙 중에는 파일 확장자를 명시해야 하는 규칙이 존재합니다.

명시하라고 타입 에러가 잔뜩 난 것이죠.. 🥹

그렇지만 타입 에러이기 때문에 tsconfig를 설정하면 컴파일러가 알아서 잘 인식해줄 것 같기도 합니다. 결론적으로는 아래와 같이 설정하면 해결됩니다.

{
  "compilerOptions": {
    "moduleResolution": "Bundler"
  }
}

🤔 moduleResolution

TypeScript가 모듈을 찾는 방식을 지정
모듈 해석 방식에 따라 import문을 해석하고 필요한 파일을 찾는 방법에 영향을 미침

다음과 설정할 수 있는 값들입니다.

node, node16, nodenext: ESM, CJS 모두 지원. 모듈을 찾는 방식이 조금씩 다르긴 하다
classic: 초기 모듈 해석 방식. node_modules를 통해 모듈 탐색 X
bundler: 번들러에 맞춰 해석 가능하도록. 파일 확장자 생략 가능

그래서 저는 bundler로 설정했습니다.

😟 "moduleResolution": "bundler"를 그냥은 못쓴단다

모노레포에서 base로 설정하고 있는 tsconfig에 moduleResolution만 오버라이드하여 설정해주려고 했더니 아래와 타입 에러는 만났습니다.

대충 module이라는 값을 맞추라는 에러 같아요 일단..?

🥹 tsconfig에서 module

TS 컴파일러가 어떤 모듈 시스템으로 해석할지를 결정하는 필드입니다.

사실 이 타입 에러 지옥은 package.json에서 "type": "module"로 설정한 후부터였는데요.

프로젝트 package.json에서 "type": "module"로 설정했다면, 프로젝트는 ESM 방식으로 동작하게 된다는 것이고 그렇다면 TypeScript도 ESM 방식으로 코드를 해석해야 합니다.

그래서 ESM으로 해석할 수 있는 ESNext | ES2015 이상으로 설정해야 합니다.

선택지가 아주 많군요!

보통 최신 스캐폴딩 도구를 사용하면 ESNext 혹은 NodeNext로 최신 문법을 사용할 수 있도록 설정되어지는 듯 합니다.

정말 최신의 문법을 사용한다면, 폴리필이 존재하는지 확인해야겠지만 저는 엄청나게 갓 나온 문법같은 건 사용하지 않았기 때문에..

그리고 특정 ES 버전으로 맞춰서 개발해야 하는 스펙도 없었기 때문에 ESNext로 설정해주었습니다. 또, 번들링 될 때 트랜스파일링 될 것도 생각이 들어 큰 문제는 없을 거라고 생각했습니다.

드디어 아무 문제 없이 빌드가 되는 것을 확인할 수 있었습니다 😂

🤔 근데 이때까지 왜 아무 문제 없이 동작했던거지?

이때까지 package.json에 type 필드를 설정하지 않아 CJS로 동작해서 tsconfig의 module: "NodeNext"가 짝짝꿍 잘 동작했던 것이라고 해봅시다.

그렇다면 저는 이때까지 어떻게 import/export문을 사용할 수 있었던걸까요?

Node.js 12 이상부터는 package.json에서 명시하지 않아도 ESM으로 처리가 가능하다고 합니다. TS 컴파일러도 파일에 import/export 문이 포함되어 있다면 이를 인식하고 변환이 가능하다고 합니다.

ESM, CJS 모두 지원하기

😟 아무튼 난 ESM으로 만들었는데, CJS도 지원하려면?

운좋게도 vite에서 ESM와 CJS를 둘 다 지원할 수 있도록 기능을 제공합니다.

// vite.config.ts
import { defineConfig } from 'vite';
import { resolve } from 'path';

export default defineConfig({
  build: {
    ...
    lib: {
      ...
      formats: ['cjs', 'es'],
    },
    ...
  },
});

그러면 아래와 같이 dist 파일 하위에 CJS 파일과 ESM 파일이 생성됩니다.

그럼 아래와 같이 package.json에 인식할 수 있도록 경로를 입력해주면 됩니다.

// package.json
"main": "./dist/index.js",
"module": "./dist/index.mjs",

.d.ts

레퍼런스들을 보면 package.json에 types 필드에 *.d.ts 파일을 넣어주더라구요. 사실 .d.ts 파일에 대한 지식도 얕고 관련되어 어떻게 설정하는지 알아보려고 합니다.

😲 .d.ts ?

TypeScript에서 사용되는 타입 정의 파일입니다.

이 파일을 통해서 JS 코드의 타입 정보를 제공하고 TS가 해당 코드를 이해하고 타입 검사를 수행할 수 있도록 도와줍니다.

🧐 그래서 왜 필요한걸까?

TypeScript는 정적 타입 검사를 통해 코드 작성 시 오류를 사전에 발견할 수 있도록 도와주는 JavaScript의 상위 집합일 뿐이지, 브라우저와 런타임에서는 JavaScript만을 이해하고 실행할 수 있습니다.

따라서, 번들링될 때 TS파일들은 전부다 타입 정보가 제거된 JS파일로 변환됩니다.

그런데, 또 우리는 라이브러리를 가지고 개발할 때 다시 또 정적 검사가 필요하기 때문에 함수의 인자나 컴포넌트의 props나 타입 정보가 필요합니다.

이럴 때 타입 정보를 제공하기 위해 .d.ts 파일이 필요한 것이죠!

플러그인으로 쉽게 생성하기

😉 플러그인으로 가능!

vite-plugin-dts 라는 플러그인을 통해 간편하게 생성이 가능합니다.

🤔 근데 이 .d.ts 파일이 사용처에서는 어떻게 매핑되어 정적 검사를 제공해줄 수 있는걸까?

TypeScript 컴파일러는 코드 작성 시 .d.ts 파일을 참조하여 타입을 확인합니다.

생성된 부분을 자세히 보면 .d.ts.map이란 파일이 같이 생성되었어요. 이 파일은 소스 맵인데, 변환된 JS에서 원본 코드를 쉽게 찾을 수 있도록 도와줍니다.

이 소스 맵 파일이 없다고 해서 매핑될 수 없다는 것은 아닙니다. 즉, 없어도 매핑은 가능!

🤔 .d.ts.map 소스 맵 파일 없어도 된다면.. 있으면 뭐가 좋은걸까?

https://stackoverflow.com/questions/17493738/what-is-a-typescript-map-file

소스 맵 파일이 있으면, 코드 에디터나 브라우저에서 이 파일을 이용할 수 있어 JS 파일 대신 TS 파일에 직접 들어가 디버깅을 가능하게 해준다고 합니다.

어쨌든 이것도 파일이며 생성에 대한 리소스가 필요하기 때문에 빌드 시간이나 크기가 늘어날 것 같기도 합니다.

유명한 라이브러리들을 직접 빌드 돌려보고 소스 맵을 생성하는지 살펴보았는데요.

react-hook-form ⭕️
@chakra-ui/react ❌
@radix-ui/react-* ⭕️ (.js.map으로 제공)

https://www.reddit.com/r/typescript/comments/uq6on1/declaration_files_needed_when_using_map_files/

위 페이지의 내용들은 조금 연식이 되긴 했지만.. 공감이 가서 가져왔는데요. 보통 디버깅이나 코드가 더 궁금하다면 공식 문서나 오픈 소스를 뜯어봄으로써 디버깅 한다고 생각합니다.

보통 라이브러리의 코드가 궁금해서 에디터를 통해서 들어가도 유의미한 정보를 얻기는 힘든 것 같아요.

그래서 내 라이브러리를 쓰는 사용자들의 디버깅을 위해 소스맵을 추가해야겠다!!! 라는 건 좀 어려울 것 같아요.

그래서 저는 소스 맵을 제외하려고 합니다.

소스맵 제외하기

이것도 tsconfig 파일을 통해 쉽게 제외할 수 있습니다.

// tsconfig.json
{
  ...
  "compilerOptions": {
    ...
    "declarationMap": false
  },
  ...
}

소스맵을 제외함으로 번들 사이즈의 축소를 기대했습니다.

아직 작고 귀여운 패키지이기에.. 소수점 2자리까지 나오는 번들 사이즈에는 차이는 없었습니다. 🤣

dist

그런데 빌드를 할 때마다 생성되는 dist 폴더는 어떻게 사용되는걸까요?

dist는 배포 파일로 볼 수 있는데요. 최종적으로 배포할 파일들이 포함됩니다.

번들러들이 소스 코드를 번들링하고 최적화하여 dist 폴더를 생성하는 것이죠!

🚀 배포!

🫢 이제 배포할 준비가 된건가..!!!!!!!!!

아래에서 버전 관리에 대해 다뤄볼 것이긴 하지만, Sementic Versioning에 따라 최초 개발 배포인 지금 0.1.0으로 업데이트 했습니다.

// package.json
"version": "0.1.0",

🙂 패키지에 대한 정보 입력해주기

// package.json
"license": "MIT",
"homepage": "https://github.com/depromeet/15th-team3-FE",
"repository": {
  "type": "git",
  "url": "https://github.com/depromeet/15th-team3-FE",
  "directory": "packages/core/sds"
},

그 전에..

난리가 났습니다.

번들에서 react를 제외하면서 고정해뒀던 버전들이 꼬인 걸로 추측됩니다.

고정되어 있던 버전들을 update 해줌으로써 사용처에서의 문제는 해결했지만

$ pnpm update

갑자기, 배포하려는 패키지에서 타입 에러 지옥에 빠지게 되었습니다 😅

원인은 이곳저곳 react 관련 패키지들이 버전이 꼬이면서 생기는 문제였습니다.

문제를 마주하게 되어 프로젝트의 package.json들을 열어보니 엉망이였습니다. 어디에는 react가 devDependencies에 들어가 있으며 (물론 소스코드에서 쓰여서 번들에 포함되긴 했나봅니다)

이곳 저곳 다른 버전을 쓰며 버전이 꼬여 에러가 발생한 걸로 보였습니다.

특정 패키지에서만 의존성을 가져야 하는 패키지와 공통으로 관리해야 할 패키지를 구분하여 package.json을 정리하니 빌드에 성공할 수 있었습니다.

진짜 npm publish

1. npm 회원가입하기

https://www.npmjs.com/signup

2. cli에서 로그인

$ npm login

아래 명령어를 실행해서 본인 username이 뜨면 로그인 성공입니다.

$ npm whoami

3. 배포

npm publish --access=public

모노레포 안에 있는 패키지를 배포하는 것이기 때문에 좀 더 설정이 필요합니다. 배포 명령어를 치면 아래와 같이 scope이 없다며 에러가 납니다.

NPM에서 Add Organization을 해줘야 합니다.

저 같은 경우에는 패키지명이@sambad/sds이므로 앞에 sambad를 입력해주었습니다.

완료 후 위 publish 명령어를 다시 입력해주면 배포 성공입니다 🎉

이제 배포된 패키지의 NPM 경로가 생기게 됩니다.

https://www.npmjs.com/package/패키지명

🚀🎉

버전 관리

업데이트 예정입니다 🎉

끝으로

번들러를 골라서 손수 빌드를 위한 것들을 챙겨준 것은 처음 경험한 작업이였습니다. 생각보다 배울 게 많았으며 문제를 겪으며 찾아보고 알게된 것들이 정말 재밌었습니다 🫢

아직 해보고 싶은 게 많아요. 버전 관리도 해보고 싶고, 버전 업데이트 시 npm 자동 배포도 구축해보고 싶고, 디자인 시스템도 성장시키고 싶고 해보고 싶은게 많습니다 🤓

Reference

CSS가 우리에게 닿기까지

Mon, 17 Jun 2024 17:08:29 GMT

이번 글에서는 다양한 CSS를 작성하는 방식을 살펴보며, 번들부터 렌더링까지 어떠한 과정이 일어나는지를 자세히 알아보려고 합니다.

최근 프로젝트를 새로 시작하게 되었어요. 스타일링 라이브러리를 선택하고 또 그것을 어떻게 사용할 것인지를 정하다 보니 제대로 공부해봐야겠다는 마음이 들어 작성해보려고 합니다 🙏🏽

브라우저에게 스타일이란

CSS를 파싱해서 CSSOM(CSS Object Model) 트리로 파싱을 한 후, DOM과 결합하여 페인트하는 것은 잘 알려진 브라우저 렌더링 과정의 일부인데요.

브라우저는 어떻게 스타일 속성을 알고 적용할 수 있는걸까요?

CSS는 W3C에서 정의한 표준입니다. 브라우저의 렌더링 엔진이 CSS 표준을 기반으로 동작합니다. CSS 명세를 구현하여 스타일 속성을 해석하고 적용하는 기능을 가지고 있어 이러한 명세를 기반으로 동작하여 스타일링을 처리합니다.

css module

*.(module).css 파일을 생성하고, CSS를 정적으로 분석하여 별도의 CSS파일로 추출하는 방식

코드로 미리보면 아래와 같습니다.

/* styles.module.css */
.button {
  background-color: blue;
  color: white;
}

// Button.js
import React from 'react';
import styles from './styles.module.css';

const Button = () => {
  return 
};

export default Button;

css module를 사용하면, 컴포넌트 기반 스타일링이 가능해서 클래스명 충돌을 방지하고 스타일을 모듈화할 수 있어요. 번들링 과정에서 모듈 간 동일한 className을 사용하더라도 충돌을 방지하게 위해 고유한 클래스 이름으로 변환됩니다.

브라우저에서 렌더링 되기 위해서는 아래 JSX를 실제 DOM 노드로 변환합니다. (위에서 말한 클래스 이름 변환 포함) 이제 이걸로 브라우저에 렌더링하게 되는 것이죠!

const Button = () => {
  return 
}

렌더링을 했으니 스타일을 적용해야 하는데, 스타일은 어디서 가져와 적용하는걸까요?

번들 과정에서 번들러는 CSS를 처리하는 로더를 통해 태그 안에