외부 패키지(라이브러리)란?
일명 기여자(Contributor)라고 불리는 개발자들이 다른 개발자들이 개발을 편리하게 할 수 있도록 자주 이용되는 소스코드 패턴들을 공유한 것이다.
이러한 소스코드를 가져오는데는 다양한 방법이 존재한다.
CDN을 이용한 방법
CDN은 Content Delivery Network의 약자이다.
위는 chart.js의 홈페이지에서 가져온 라이브러리 임포트 방법인데,
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>라는 코드를 추가하여, 자신의 라이브러리를 임포트하라고 권장하고 있다.
CDN의 장점
- CDN은 가장 간단하게 라이브러리를 임포트할 수 있는 방법이다. 따로 내가 해당 라이브러리를 직접 설치할 필요도 없다.
- HTML 코드에 script 태그 한줄만 추가해주면 된다.
- 라이브러리 트래픽을 내 서버에서 받아낼 필요가 없다.
- CDN 서버에서 해당 라이브러리를 제공하는 모든 트래픽을 받아준다.
- 전 세계 어디에서 접근해도 균일한 속도를 내줄 수 있다.
- CDN의 서버는 전세계에 존재해서 요청이 들어왔을 때, 요청지에서 가장 가까운 서버를 이용해 응답해준다.
- 웹사이트 접근속도가 빨라지면 구글 SEO(검색엔진 최적화)에도 좋은 영향을 준다.
- 라이브러리의 버전이 올라갔을 때, 그냥 참조하는 웹사이트 URL에서 버전만 올려주면 된다.
CDN에 대한 상세한 설명 블로그
CDN의 단점
- CDN 서버가 무너지면, CDN을 이용하던 모든 웹사이트가 다 동작하지 않을 수 있다. (실제로도 이런일이 종종 일어난다.)
- 인터넷이 안되는 PC에서 이용이 불가능하다.
- 중국의 경우 CDN이 제공되지 않을 수 있다.
- 폐쇄적인 인터넷 망을 사용하기 때문
- 중국은 유튜브도 못 보는 국가이다.
- 무료 CDN을 사용할 때는 자신의 사이트 정보도 함께 전송되기 때문에 보안에 위협이 될 수도 있다.
직접 다운로드 하는 방법
CDN이나 라이브러리 원본 URL에 접근하여 서버나 로컬 PC에 저장해두고 개발에 이용하는 방법이다.
장점
- 인터넷에 연결되지 않거나, 해당 라이브러리를 제공하는 서버에서 장애가 발생해도 무관하다.
단점
- 직접 일일이 다운받아야 한다. (귀찮다.)
- 라이브러리 업데이트가 되었을 때도 직접 새로운 버전을 다운받으러 가야한다.
- 한가지 라이브러리만 이용한다면 상관없지만, 20개 30개의 라이브러리를 참조하는 프로젝트를 관리한다면, 엄청난 작업이 될 것이다.
- 라이브러리끼리 서로 상호적으로 의존할 때 호환되는 버전들을 찾기 엄청나게 귀찮을 것이다.
- jquery의 경우엔 jquery를 의존하는 서브 라이브러리들이 엄청 많다. 서브 라이브러리에 알맞은 jquery 버전을 사용해야 하는데, 그걸 일일이 알아보고 찾아다니고 다운로드받는데 엄청난 시간을 소비할 것이다.
한마디로 얘기하면 자동화가 안된다.
NPM으로 의존성을 관리하는 방법
이게 가장 권장되는 패키지 관리 방법이다. NPM에 대해 알아보자.
NPM이란?
기본적으로 nodejs로 만들어진 프로젝트를 관리하는 도구이며, NPM이라는 거대한 패키지 저장소에서 우리가 원하는 라이브러리를 받아와 쓰는 것이다.
package.json
NPM은 다음과 같은 package.json이라는 파일로 프로젝트의 의존성들을 관리한다.
{
"name": "1_todo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"@babel/core": "^7.9.0",
"@babel/preset-env": "^7.9.5",
"@babel/preset-typescript": "^7.9.0",
"@typescript-eslint/eslint-plugin": "^2.27.0",
"@typescript-eslint/parser": "^2.27.0",
"eslint-plugin-prettier": "^3.1.2",
"prettier": "^2.0.4",
"typescript": "^3.8.3"
},
"dependencies": {
"eslint": "^7.32.0"
}
}위에 보면, 프로젝트 이름, 버전, 설명, 메인 js, 사용자 정의 빌드 스크립트, 키워드, 작성자, 라이센스, 의존성 등 많은 정보를 볼 수 있다.
NPM의 버전 관리 방법 1. Semantic Versioning
라이브러리는 시간을 두고 새로운 기능이 만들어지거나 버그가 수정되며 계속 업데이트되기 마련이다.
이러한 버전을 관리하는 것은 생각보다 중요하다. NPM은 버전 관리를 위해 Semantic Versioning이라는 방식을 쓴다.
위의 package.json의 예를 보면 eslint의 버전은 ^7.32.0이다.
버전을 보면 .이 두개가 붙어 있고, 3개의 구역에 각각 숫자가 배치되어 있다. 여기서 숫자가 배치된 위치가 중요하다.
- 첫번째 숫자는 'Major Version'을 의미한다.
- 기존 버전과 호환되지 않게 변경이 일어났을 경우, 이 버전을 업데이트한다.
- 두번째 숫자는 'Minor Version'을 의미한다.
- 기존 버전과 호환이 되는데, 단순히 기능이 추가됐을 경우, 이 버전을 업데이트한다.
- 세번째 숫자는 'Patch Version'을 의미한다.
- 기존 버전과 호환도 되고 기능도 그대로인데, 버그를 수정했을 경우 이 버전을 업데이트한다.
NPM에 등록된 모든 라이브러리들은 이 Semantic Versioning을 따르기 때문에, 어떤 부분이 업데이트 됐는지 알아보기 좋다.
NPM의 버전 관리 방법 2. 버전의 범위, 부등호와 틸트(~)와 캐럿(^)
버전을 기재하는데만 해도 총 4가지 방법을 사용할 수 있다.
CASE 1: 그냥 버전을 입력하는 경우
"dependencies": {
"eslint": "7.32.0"
}가장 간단한 케이스다. 7.32.0 버전을 의미한다.
CASE 2: 부등호를 이용한 경우
"dependencies": {
"eslint": ">=7.32.0"
}이건 일반적으로 수학에서 부등호가 갖는 의미와 같다. 7.32.0 보다 크거나 같은 버전을 의미한다.
CASE 3: 틸트(~)를 이용한 경우 - Patch Version 업데이트
"dependencies": {
"eslint": "~7.32.0"
}이 경우에는 이전에 설명했던 Patch Version에 업데이트가 있는 경우에만 버전을 최신 버전으로 업데이트한다. Major Version이나 Minor Version이 업데이트 된 것에 대해서는 관여하지 않는다.
~7.32.0은7.32.0 ~ 7.32.xx버전을 포함할 것이다.
CASE 4: 캐럿(^)을 이용한 경우 - Minor Version, Patch Version 업데이트
"dependencies": {
"eslint": "^7.32.0"
}이 경우에는 이전에 설명했던 Minor Version과 Patch Version에 업데이트가 있는 경우에 버전을 최신 버전으로 업데이트한다. Major Version이 업데이트 된 것에 대해서는 관여하지 않는다.
^7.32.0은7.xx.xx버전을 포함할 것이다.
node.js에서는 일반적으로 캐럿(
^)을 이용하여 버전을 명시한다.
NPM 버전 관리 함정: 정식 릴리즈 전의 패키지
정식 릴리즈 전의 패키지는 Semantic Versioning의 룰을 지키지 않는 경우도 더러 있다. 특히나 Minor Version을 업데이트 했음에도 하위 호환성이 지켜지지 않아 잘 작동하던 프로젝트가 작동하지 않는 경우도 있으니 주의해야 한다.
node.js에서는 일반적으로 캐럿(^)을 이용하여 버전을 명시하는데, 그 이유는 기존에 ~0과 같이 틸트로 버전을 명시했다가 0.0.0부터 0.x.x로 버전이 업데이트되어 하위 호환성이 지켜지지 않았던 적이 있다.
그래서 요즘은 ^0.0과 같이 캐럿으로 버전 표기를 하는 편이다.
react의 경우 위와 같이0.대 버전이 매우 많은데~0과 같이 버전을 입력하면 자동으로 최신인0.14.10버전이 설치된다. 만일,0.0.1버전을 사용하다가 갑자기0.1.0버전으로 버전업되어 라이브러리 호환이 되지 않는다면 굉장히 당황할 수 있다.
node_modules내부로 들어가서 패키지 디렉토리를 찾아들어가보면 내가 현재 사용하고 있는 버전을 알 수 있다.
