Webpack 알아보기 (1)

삔아·2021년 11월 6일

목록 보기

1/4

📢 해당 글은 인프런 강의(https://www.inflearn.com/course/프런트엔드-웹팩/dashboard) 를 기반으로 작성한 글 입니다.
해당 글의 웹팩 버전은 4.41 기준으로 작성하였습니다.

1. Webpack 소개

💡 웹팩이란 최신 프론트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러(Module Bundler) 입니다.

(1) Webpack 설명에 앞서

최신 자바스크립트 개발에서 모듈은 절대 빠져서는 안 될 용어 중 하나 입니다.
이와 동시에, 자바스크립트 파일을 기능 단위로 모듈화 하고 이것을 하나로 묶어 관리할 방법이 필요하게 되면서 번들러의 역할이 중요해졌습니다.

먼저, 모듈과 번들러에 대해 간략히 설명을 드리고 이야기를 다시 시작하겠습니다.

모듈은 프로그래밍 관점에서 특정 기능을 갖는 작은 코드 단위를 의미합니다.

자바스크립트로 치면 아래와 같은 코드가 모듈 입니다.

// math.js
function sum(a, b) {
  return a + b;
}

function substract(a, b) {
  return a - b;
}

const pi = 3.14;

export { sum, substract, pi }

이 math.js 파일은 아래와 같이 3가지 기능을 갖고 있는 모듈 입니다.

두 숫자의 합을 구하는 sum() 함수
두 숫자의 차를 구하는 substract()함수
원주율 값을 갖는 pi 상수

이처럼 성격이 비슷한 기능들을 하나의 의미 있는 파일로 관리하면 모듈이 됩니다.

모듈을 프로그램의 꾸러미라고 할 수 있는데요. 이를 사용하는 이유는 바로 효율성 때문입니다.
매우 복잡하고 긴 코드를 작성할 때 사용 용도에 따라 파일 단위로 구분한 뒤, 다른 파일에서 해당 클래스나 함수가 필요할 때 가져와서 사용할 수 있도록 해줍니다.

번들러는 의존성이 있는 모듈 코드를 하나(또는 여러개)의 파일로 만들어 주는 도구 입니다.

브라우저 환경에서는 CommonJS나 일부 ES6 Module로 작성된 코드는 바로 실행할 수 가 없으므로 모듈 코드를 분석하고 자바스크립트 모듈 스펙에 따라 새로운 코드로 가공하는 작업이 필요합니다.
바로 이 작업을 해주는 것이 번들러의 역할 입니다.

💡 따라서 모듈 번들러는 웹 애플리케이션을 구성하는 웹 자원(HTML, CSS, Javscript, Images 등)을 모두 각각의 모듈로 보고 이 자원들의 의존성 관계들을 묶고 조합하여 병합된 하나의 결과물을 자동으로 만들어 주는 도구를 의미합니다.

(2) Webpack 등장 배경

최신 프론트엔드 프레임워크는 서버사이드 템플릿 시대를 지나 싱글 페이지 애플리케이션(Single Page Application, SPA) 개발이 인기를 얻으면서 나타나게 되었으며 그로 인해 자바스크립트의 코드량이 기하급수적으로 증가하게 됩니다.
이에따라 코드량이 많게는 수천, 수만 줄에 이르게 되고 자바스크립트 코드에서 특정 코드를 찾아 수정하기 까다로워지기 때문에 개발 초기 단계에 API 기능과 UI 컴포넌트에 맞도록 자바스크립트 코드를 모듈별로 분리하게 되었는데요.

하지만, 분리해 놓은 여러 개 혹은 수많은 자바스크립트 파일들을 하나씩 따로 로드해 온다면 웹 페이지 로딩시 커다란 속도 저하 문제가 발생할 여지가 있습니다.

네트워크패널 - 14개의 파일 요청 (0.1초)

저속의 네트워크 환경 (1.32초)

한 유투브영상 에서 가져온 예시 입니다. 해당 예시의 웹사이트는 14개의 파일을 요청하여 보여졌으며, 네트워크 패널로 확인 한 결과 요청시간이 0.1초 인것을 확인 할 수 있는데요.

네트워크 패널의 우측 상단에 No throttling 을 이용하여 네트워크의 지연시간 이나 가상환경 을 설정하여 저속의 네트워크 환경에서 시작을 하면 두번째 사진처럼 요청 시간이 지연 되었다는 부분을 확인 할 수 있습니다.

웹페이지는 수 많은 구성요소로 이루어져 있으며, 기본적인 HTML, CSS, JS 파일 외에도 웹폰트, 이미지, json 데이터 등등 수 많은 파일들을 요청하고 받아와야 합니다. 이 수많은 파일들은 하나의 요청이 끝나야 다음 요청을 보낼 수 있기 때문에 요청이 많을수록 비효율적일 수 밖에 없는데요.

이 요청 수 를 줄이기 위해 이미지는 스프라이트화 시켜서 한 번만 로드 할 수 있도록 하기도 했으며 js, css 파일을 하나로 합치는 작업을 하기 위해 웹팩이 나타나기 전까지는 Gulp, Grunt 같은 task runner 빌드 도구들로 개발 생산성을 높였습니다.

그렇다면, Gulp, Grunt 같은 Web Task Manager 가 있는데 웹팩이 왜 등장하게 되었을까요?

과거에 모듈 의존성 관리를 하기 위해서는 자바스크립트(ES5 기준)는 언어 자체적으로 모듈화를 지원하지 않기 때문에 모듈화를 위한 라이브러리나 도구들이 생겼고 Gulp, Grunt에 라이브러리나 그 기능들을 따로 추가적으로 설치하여 사용할 수 있었지만 웹팩은 웹팩 자체만으로 webpack -p라는 명령어를 수행(CLI로 실행 가능)하면 minification을 상용화된 서비스를 제공해 주는 큰 차이점을 가지고 있습니다.

즉, 웹팩은 기존 Web Task Manager(Gulp, Grunt)의 기능 + 모듈 의존성 관리까지 할 수 있는 통합 웹 개발 도구라고 할 수 있습니다.

⚠️ 참고

Grunt or Gulp vs Webpack 의 차이 에 대해서는 해당 링크를 참고해주세요.

초기의 ES5 자바스크립트 코드 기반의 모듈 관리라는 것은 언어 자체적으로 지원이 되지 않았기 때문에 복잡한 웹 앱을 관리하기 위해 자바스크립트 파일을 모듈 단위로 관리하는 AMD, CommonJS, ES6(Modules) 기타 모듈로더들이 등장했었고 이를 모두 통합해서 사용할 수 있는 도구가 Webpack 입니다.
기존 도구들로도 수많은 라이브러리를 연동해서 모듈로더를 사용하고 성능 최적화를 시킬 수 있었으나 Webpack은 기존 모듈로더들의 장점을 수용하면서 좀더 나아가 가독성이나 다수 모듈 미병행 처리등의 약점을 보완하면서 하여 상용화된 서비스를 제공해 준다는 장점이 있습니다.
그렇기 때문에 크고 복잡한 다양한 리소스들이 들어있는 프로젝트에는 Webpack 을 사용하는 것이 최상의 선택이 될 수 있습니다.그리고 Browserify 는 Webpack 과 유사한 도구이지만, 속도면에서 Webpack 이 더 우월하다고 평가받고 있습니다.
출처: https://webclub.tistory.com/635?category=718289

웹팩이 등장한 이유는 크게 3가지로 볼 수 있습니다.

파일 단위의 자바스크립트 모듈 관리의 필요성
웹 개발 작업 자동화 도구 (Web Task Manager)
웹 애플리케이션의 빠른 로딩 속도와 높은 성능

파일 단위의 자바스크립트 모듈

입문자 관점에서 고안된 자바스크립트는 아래와 같이 편리한 유효 범위를 갖고 있습니다.

var a = 10;
console.log(a); // 10

function logText() {
  console.log(a); // 10
}

자바스크립트의 변수 유효 범위는 기본적으로 전역 범위를 갖습니다.
최대한 넓은 변수 범위를 갖기 때문에 어디에서도 접근하기가 편리합니다.

그런데 이러한 장점이 실제로 웹 애플리케이션을 개발할 때는 아래와 같은 문제점으로 변합니다.

<!-- index.html -->
<html>
	<head>
		<!-- ... -->
  	</head>
	<body>
		<!-- ... -->
      		<script src="./app.js"></script>
      		<script src="./main.js"></script>
	</body>
</html>

// app.js
var num = 10;
function getNum() {
  console.log(num);
}

// main.js
var num = 20;
function getNum() {
  console.log(num);
}

위와 같이 index.html에서 두 자바스크립트 파일을 로딩하여 사용한다고 해봅시다.

스크립트에 아래와 같이 코드를 실행하면 어떤 결과가 나올까요?

<!-- index.html -->
<html>
	<head>
		<!-- ... -->
  	</head>
	<body>
		<!-- ... -->
          <script src="./app.js"></script>
          <script src="./main.js"></script>
          <script>
            getNum(); // 20
          </script>
	</body>
</html>

결과는 20입니다. app.js에서 선언한 num 변수는 main.js에서 다시 선언하고 20을 할당했기 때문인데요.

이러한 문제점은 실제로 복잡한 애플리케이션을 개발할 때 발생합니다.
변수의 이름을 모두 기억하지 않은 이상 변수를 중복 선언하거나 의도치 않은 값을 할당할 수 있습니다.

// a.js
// var num = 10;
var a = {
  num: 10
}
a.num // 10

// b.js
// var num = 20;
var b = {
  num: 20
}
b.num // 20

따라서 위 코드와 같이 네임스페이스패턴 을 이용해서 문제들을 해결하거나 require 를 이용하여 라이브러리 차원에서 모듈의 개념들을 만들어 나갔었습니다.

이처럼 파일 단위로 변수를 관리하고 싶은 욕구, 자바스크립트 모듈화에 대한 욕구를 웹팩이 등장하기 전까진 AMD, Common.js와 같은 라이브러리로 풀어왔습니다.

웹 개발 작업 자동화 도구 (Web Task Manager)

이전부터 프론트엔드 개발 업무를 할 때 가장 많이 반복하는 작업은 텍스트 편집기에서 코드를 수정하고 저장한 뒤 브라우저에서 새로 고침을 누르는 것이었습니다. 그래야 화면에 변경된 내용을 볼 수 있었죠.

이외에도 웹 서비스를 개발하고 웹 서버에 배포할 때 아래와 같은 작업들을 해야 했습니다.

HTML, CSS, JS 압축
이미지 압축
CSS 전처리기 변환

이러한 일들을 자동화 해주는 도구들이 필요했습니다. 그래서 Grunt와 Gulp 같은 도구들이 등장했습니다.

웹 애플리케이션의 빠른 로딩 속도와 높은 성능

일반적으로 특정 웹 사이트를 접근할 때 5초 이내로 웹 사이트가 표시되지 않으면 대부분의 사용자들은 해당 사이트를 벗어나거나 집중력을 잃게 됩니다.

그래서 웹 사이트의 로딩 속도를 높이기 위해 많은 노력들이 있었습니다. 그 중 대표적인 노력이 브라우저에서 서버로 요청하는 파일 숫자를 줄이는 것입니다. 이를 위해 앞에서 살펴본 웹 태스크 매니저를 이용해 파일들을 압축하고 병합하는 작업들을 진행했습니다.

뿐만 아니라 초기 페이지 로딩 속도를 높이기 위해 나중에 필요한 자원들은 나중에 요청하는 레이지 로딩(Lazy Loading) 이 등장했습니다.

웹팩은 기본적으로 필요한 자원은 미리 로딩하는게 아니라 그 때 그 때 요청하자는 철학을 갖고 있습니다.

(3) Webpack으로 해결하려는 문제 4가지

웹팩의 등장 배경에서도 살펴봤지만 웹팩에서 해결하고자 하는 기존의 문제점은 다음 4가지 입니다.

자바스크립트 변수 유효 범위
브라우저별 HTTP 요청 숫자의 제약
사용하지 않는 코드의 관리
Dynamic Loading & Lazy Loading 미지원

자바스크립트 변수 유효 범위 문제

웹팩은 변수 유효 범위의 문제점을 ES6의 Modules 문법과 웹팩의 모듈 번들링 으로 해결하고 있습니다.

브라우저별 HTTP 요청 숫자의 제약

TCP 스펙에 따라 브라우저에서 한 번에 서버로 보낼 수 있는 HTTP 요청 숫자는 제약되어 있습니다. 아래의 표는 최신 브라우저 별 최대 HTTP 요청 횟수입니다.

HTTP 요청 숫자를 줄이는 것이 웹 애플리케이션의 성능을 높여줄 뿐만 아니라 사용자가 사이트를 조작하는 시간을 앞당겨 줄 수 있습니다.

⚠️ 알아두면 좋아요!
클라이언트에서 서버에 HTTP 요청을 보내기 위해서는 먼저 TCP/IP가 연결되어야 합니다.

웹팩을 이용해 여러 개의 파일을 하나로 합치면 위와 같은 브라우저별 HTTP 요청 숫자 제약을 피할 수 있습니다.

Dynamic Loading & Lazy Loading 미지원

Require.js와 같은 라이브러리를 쓰지 않으면 동적으로 원하는 순간에 모듈을 로딩하는 것이 불가능 했습니다. 그러나 이젠 웹팩의 Code Splitting ****기능을 이용하여 원하는 모듈을 원하는 타이밍에 로딩할 수 있습니다.

⚠️ 참고
쓰지않는 라이브러리는 tree-shaking 으로 떨구어낼 수 있습니다.

💡 Webpack 철학

모든 것은 모듈이다.
모든 웹 자원(js, css, html, img, webfont...)을 모듈 형태로 로딩이 가능합니다.
보통 css, html 을 자바스크립트로 로딩( )이 되지 않기 때문에 모듈로 보기 어려운데요.
하지만 Webpack 은 css, html, images 등을 자바스크립트로 변환이 가능하도록 지원하고 있습니다.

초기에 불필요한 것들을 모두 로딩 하지 않고, 필요할 때에 필요한 것만 로딩하여 사용.

📢 웹팩에 대한 이야기에 집중하고자, 다른 번들러에 대한 내용은 해당 페이지에서 작성하지 않았습니다.
만약 다른 번들러와의 비교에 대해 알아보고 싶으시면 이곳 을 참고해주세요!

2. Webpack 개발환경 설정에 필요한 배경 지식

웹팩을 사용하기 위해서는 개발환경 설정에 필요한 사전 지식들이 필요합니다.

먼저, 개발 환경 설정에 필요한 Node.js, NPM(Node Package Manager) 을 짚고간 뒤에 웹팩 설정에 대해 알아보도록 하겠습니다.

(1) Node.JS

💡 Node.js 는 자바스크립트를 개발 언어로 사용하는 소프트 웨어 플랫폼 입니다.
또한 브라우저 밖에서도 자바스크립트를 실행할 수 있는 환경을 의미하기도 합니다.

Webpack을 포함한 대부분의 번들러에 필요한 구성 파일들, 라이브러리등의 기타 수많은 파일들은 Node.js 그리고 NPM 을 설치해야 필요한 구성 파일들의 패키지를 다운 받아서 설치하고 구성할 수 있습니다.

만약 설치되어 있지 않다면, Node.js사이트 에서 설치 받아 주세요.

Node.js 더 알아보기..

(2) NPM (Node Package Manager)

💡 전세계 자바스크립트 라이브러리가 있는 공개 저장소

NPM은 명령어로 자바스크립트 라이브러리를 설치하고 관리할 수 있는 패키지 매니저 입니다.
Gulp, Grunt, Webpack 모두 node 기반으로 NPM을 사용하여 필요한 라이브러리들을 로딩합니다.

Node.js를 설치하면 NPM 역시 같이 설치가 되기 때문에, 따로 설치해 줄 필요는 없습니다.

Package.json

NPM의 패키지는 package.json 에 정의되어집니다. npm init 명령어를 통하면 최초에 이 파일이 만들어지고, 패키지를 설치하게 되면 package.json에 명시가 됩니다.
또한 설치한 패키지가 이름이 무엇인지, 라이센스가 어떻게 되는지 등 패키지에 대한 정보를 명시합니다.

Package-lock.json

해당 파일은 최초 npm init 을 실행시 생성되지는 않습니다. 이 파일은 npm 패키지를 설치하거나 수정, 삭제 등의 작업을 진행할 때 생성되며 핵심 역할은 각 패키지에 대한 의존성 관리 입니다.

하나의 패키지를 여러 패키지에서 사용할 수 있고 하나의 패키지는 여러 개의 버전을 가지며 또 이 여러 버전을 다른 패키지에서 사용할 수 있는데요. 이렇게 되면 패키지 버전 간의 충돌과 호환이 되지 않는 경우를 미연에 방지하기 위함 입니다.

(3) NPM 명령어

1. npm init

npm init

먼저 Webpack 을 구성하기 전에 프로젝트의 node modules를 관리하기 위해 package.json을 설정 해주어야 합니다.

초기화 명령어인 npm init 을 입력 해줍니다.

npm init 을 실행 한 후 엔터를 계속 치면 종합해서 올바르게 입력했는지 다시 확인 요청

그 후 yes (엔터) 로 넘어가게 되면 package.json 이 생성 됩니다.

💡 이때, npm init 이 아니라 npm init -y 를 입력하게 되면 엔터로 일일히 넘어가지 않아도 기본 값으로 설정이 됩니다.

2. npm install (특정 라이브러리) : NPM 설치 명령어

npm install 특정라이브러리
// npm install jquery

일반적으로 특정 라이브러리가 설치 되었을 때 에는, 해당 라이브러리 폴더 밑에 있는 소스 중에 필요한 소스가 있는데요. dist 라는 폴더에 소스들을 확인 할 수 있습니다.

또한, npm 밑에 있는 package.json 확인 하면 dependcies 에 특정 라이브러리 (예. jqeury) 를 확인 할 수 있습니다.

2-1. Global 설치 VS Local 설치

위의 jquery 모듈을 설치한 것은 현재 프로젝트의 로컬 폴더 node_modules 하위 디렉토리의 로컬 설치를 하게 되는 것이지만, global 로 설치하는 것은 운영체제마다 설치되는 공간은 다르겠으나 운영체제마다의 시스템 레벨 내에서의 패키지를 전역적으로 설치하게 됩니다.

NPM 전역 설치

NPM 전역 설치는 위와 같이 프로젝트에서 사용할 라이브러리를 불러올 때 사용하는 것이 아니라 시스템 레벨에서 사용할 자바스크립트 라이브러리를 설치할 때 사용합니다.

npm install 특정라이브러리 --global
npm i 특정 라이브러리 --g

라이브러리가 설치되고 나면 node_modeules 에서 확인 할 수 없지만, 명령어 실행 창에 해당 라이브러리 이름을 입력했을 때 명령어를 인식합니다.

npm i webpack --global 을 실행하게 되면 webpack 명령어를 어느 디렉토리에서나 수행할 수 있습니다. 즉 다른 디렉토리로 이동하여 해당 디렉토리 내에서 아래와 같은 명령어를 실행하면 webpack 버전을 확인하실 수 있습니다.

다시 말해, 전역 설치는 간혹 패키지를 현재 디렉토리 뿐만 아니라 어디서나 실행할 수 있도록 설치해야 할 경우들이 있을 수 있기 때문에 사용합니다.

NPM 전역 설치 경로

전역 설치된 자바스크립트 라이브러리는 어느 위치에서 해당 명령어를 실행했던지 간에 OS별로 아래와 같은 폴더 경로에 설치됩니다.

# window
%USERPROFILE%\AppData\Roaming\npm\node_modules

# mac
/usr/local/lib/node_modules

NPM 지역 설치 및 경로

지역 설치로 라이브러리를 설치하면 해당 프로젝트의 node_modules 라는 폴더가 생깁니다.
그리고 그 폴더 아래에 해당 라이브러리 파일들이 설치되어 있는 것을 확인할 수 있습니다.

NPM 지역 설치에 자주 사용되는 2가지 옵션은 다음과 같습니다.

npm install jquery --save-prod
npm install jquery --save-dev

위 명령어는 아래와 같이 각각 축약할 수 있습니다.

npm i jquery
npm i jquery -D

여기서 설치 옵션에 아무것도 넣지 않은 npm i jquery는 package.json의 dependencies에 등록됩니다.

하나의 예시로 vue 를 --save-dev (-D) 를 통해 설치 해보겠습니다.

npm install vue --save-dev
npm i vue -D

{
  "name": "npm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "jquery": "^3.6.0",
    "jquery-ui": "^1.13.0"
  },
  "devDependencies": {
    "vue": "^2.6.14"
  }
}

⚠️ 알아두면 좋아요
dependencies 와 devDependencies 의 차이점
dependencies 는 애플리케이션의 로직과 연관이 있는. 예를들어 제이쿼리는 화면의 돔을 추적하기 위한 유틸성 라이브러리, jquery-ui 도 jquery의 화면 돔 조작을 도와주는 부가적인 라이브러리로 전부 다 애플리케이션의 로직을 구현하는데에 연관이 있습니다.
화면의 로직과 직접적인 연관이 있는 로직.
ex) react, angular, chart, vue ... 등
devDependencies : webpack, js-compression, sass...
개발을 할 때 도움을 주는 개발용으로 개발 보조 라이브러리가 들어갑니다.

3. npm uninstall (특정 라이브러리) : 제거 명령어

npm uninstall 특정 라이브러리

설치한 패키지 중에 더이상 사용하지 않거나, 잘못 설치한 경우 삭제 할 수 있습니다.

패키지가 삭제되었는지는 npm list 를 사용하여 확인 할 수 있습니다.

4. NPM 커스텀 명령어

NPM 커스텀 명령어란 사용자가 임의로 명령어의 이름과 동작을 정의해서 사용할 수 있는 기능을 의미합니다.

{
  ...
  "scripts": {
    "hello": "echo hi"
  }
}

NPM 패키지 관리 파일인 package.json에 위와 같이 scripts라는 속성을 추가할 수 있습니다.
그리고 아래의 명령어를 실행하면 콘솔에 hi 가 출력됩니다.

npm run hello

이처럼 명령어 실행 창에 매번 긴 명령어를 입력할 필요 없이 커스텀 명령어를 이용해 원하는 동작을 실행할 수 있습니다.

NPM 커스텀 명령어는 모두 npm run 명령어 이름 형식으로 실행할 수 있습니다.

NPM 커스텀 명령어 실제 사례

NPM 커스텀 명령어는 웹팩 같은 도구 뿐만 아니라 Node.js 등을 사용할 때도 유용합니다.

앞에서 배운 내용으로 실제 커스텀 명령어 사례를 몇 가지 살펴보겠습니다.

"scripts": {
  "dev": "node server.js",
  "build": "webpack --mode=none",
}

위 코드는 서버를 실행하는 dev 명령어와 웹팩으로 빌드하는 build 명령어를 정의한 코드입니다. 사용자는 매번 node server.js와 webpack --mode=none를 칠 필요 없이 npm run dev와 npm run build를 입력하면 됩니다.

💡 **mode** 웹팩4에서 추가되었습니다. mode가 development면 개발용, production이면 배포용입니다. 배포용일 경우에는 알아서 최적화가 적용됩니다. 따라서 기존 최적화플러그인들이 대량으로 호환되지 않습니다.

아래와 같이 실행하려는 명령어가 길수록 더 빛을 발휘합니다.

"scripts": {
  "build": "cross-env NODE_ENV=production webpack --progress --hide-modules"
}

매번 긴 명령어를 실행하는 것보다 커스텀 명령어를 사용하는 것이 더 편하다는 것이 느껴질 것 입니다.

NPM 커스텀 명령어 실전 활용

커스텀 명령어의 또 다른 장점은 해당 명령어에 실행 옵션 뿐만 아니라 다른 커스텀 명령어를 조합할 수 있다는 점입니다.

"scripts": {
  "build": "webpack",
  "deploy": "npm run build -- --mode production"
}

위와 같은 scripts 속성을 정의하고 아래 명령어를 입력해봅시다.

npm run deploy

먼저 build에 정의한 webpack 명령어가 실행되면서 명령어 뒤쪽에 붙은 실행 옵션들이 수행됩니다. 이후 더 자세히 살펴보겠지만 여기서는 webpack이라는 도구의 mode에 production이라는 값을 넘겨준 명령어 입니다.

(4) 개발용 라이브러리와 배포용 라이브러리 구분하기

NPM 지역 설치를 할 때는 해당 라이브러리가 배포용(dependencies)인지 개발용(devDependencies)인지 꼭 구분해주어야 합니다.
예를 들어, jquery와 같이 화면 로직과 직접적으로 관련된 라이브러리는 배포용으로 설치해야 합니다. 아래와 같이 말이죠.

# 배포용 라이브러리 설치
npm i jquery

{
  "dependencies": {
    "jquery": "^3.4.1"
  }
}

이렇게 설치된 배포용 라이브러리는 npm run build로 빌드를 하면 최종 애플리케이션 코드 안에 포함됩니다.

그런데 만약 반대로 설치 옵션에 -D를 주었다면 해당 라이브러리는 빌드하고 배포할 때 애플리케이션 코드에서 빠지게 됩니다.

따라서, 최종 애플리케이션에 포함되어야 하는 라이브러리는 -D로 설치하면 안 됩니다.

개발할 때만 사용하고 배포할 때는 빠져도 좋은 라이브러리의 예시는 다음과 같습니다.

webpack : 빌드 도구
eslint : 코드 문법 검사 도구
imagemin : 이미지 압축 도구

(5) NPM을 사용하는 이유와 장점

라이브러리의 목록과 각각의 버전들을 바로 확인 할 수 있습니다.
( ⇒ package.json 에서 dependencies 확인 )
CDN 입력을 안해도 됩니다. ( 검색 할 시간 줄어듦 )
```
<script src="https://code.jquery.com/jquery-1.12.4.min.js">
....
</script>
...
```
cdn 주소로 입력을 하게되면 코드가 불필요하게 길어질 수 있거나, 매번 다른 파일마다 작성해주어야 한다는 번거로움이 있었는데요. 또한 주소를 매번 찾아주어야 한다는 점이 번거로울 수 있습니다.

하지만, npm install jquery-ui 명령어를 이용하여 jquery-ui 라이브러리를 설치 한다면, 매번 cdn주소를 입력하지 않아도 언제나 자유롭게 사용이 가능합니다.
```
{
  "name": "npm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "jquery": "^3.6.0",
    "jquery-ui": "^1.13.0"
  }
}
```
해당 페이지로 가서 cdn을 불러오지 않아도, install했을때, 내 로컬 환경에 맞추어 필요한 라이브러리가 설치가 되어 그 라이브러리를 바로 들고와서 쓸 수 있다는 장점입니다.

💡 실제 애플리케이션을 만들 때 자주 사용되는 속성은 다음과 같습니다.

scripts

dependencies

devDependencies

삔아

Frontend 개발자 입니다, 피드백은 언제나 환영 입니다

다음 포스트