●이론_1_Node.js에서 다른 사람들의 모듈을 사용하기 //서드파티 모듈
○ 명칭 정리 :
- 서드 파티 모듈 : Node.js에서 다른 개발자가 개발한 모듈들 전체를 통틀어 일컫는 말임
- npm (node package manager)
- npm registory : Node.js에서 서드 파티 모듈을 가져오게 하는 관리자 의미 같음
- date-fns : 서브 파티 모듈 중 날짜를 다룰 수 있는 모듈을 의미
○ 서드 파티 모듈 셋팅 방법 :
- 순서1_ 터미널 창 열기 //ctrl + '`'//백키
- 순서2_ 명령어 작성 후, enter
npm install date-fns- 순서3_ 디렉토리 탐색기를 보면, 아래와 같이 [node_modules] , [package-lock.json] , [package.json] 3개가 생성됨
※참고1_ [node_modules]폴더 내 [date-fns]디렉토리(폴더) 들어가보자
※참고2_ 터미널 실행한 디렉토리에서만 서브파티 모듈을 사용할 수 있다. => 즉, 다른 vscode 디렉토리에서는 사용 불가능 //가능하려면, 또 "npm install date-fns"을 터미널 입력하여, 모듈 설치 해야함
- 순서4_date-fns 서브파티 모듈을 이용하여, 현재날짜를 문자열로 출력해보기
import {format} from 'date-fns'; //서브 파티 모듈인 [date-fns] 모듈 import 한 후, format 메소드 불러오기
const dateString = format(new Date(),'MM/dd/yyyy');//dateString 변수에 , 현재 날짜를 문자열로 저장
//format() 매개인자 1 : Date 객체 , 매개인자 2 : 날짜를 변환 형식
console.log(dateString); //출력그리고, ctrl + F5 누르면, 알아서 node.js로 디버깅 된다.
●이론_2_ 참고 개념 : 내가 가져온 서브 파티 모듈 파헤치는 방법 :
▶ 개념1_ 예를 들어, [date-fns] 모듈을 어떻게 이용해야할지를 공식문서로 쳐다보고 싶다면,
①. Google 검색창에 " date-fns " 검색
②. 맨위 링크 접속
③. "document" 버튼 클릭
=> 다양한 모듈 내 function , 변수, 설치방법 등등이 있댄다.
▶ 개념2_ [개념1]에서 다른 서브파티모듈의 사이트를 들어가보면, 설명이 다 CommonJS문법으로 되어있어 좆같음
=> require 을 export default로 보는 연습만 참고하자 일단,
// CommonJS Module
const foo = require('module');
//=> import foo from 'module': 'module'의 모듈에서 default된 변수 상수 메소드를 foo객체로 사용하겠다는 뜻
// CommonJS Module
const express = require('express');
//=> import express from 'express': 'express'의 모듈에서 default된 변수 상수 메소드를 express로 사용하겠다는 뜻◎ 연습문제 :
axios 공식 문서에는 아래와 같은 예시가 있습니다.
const axios = require('axios');
// Make a request for a user with a given ID
axios.get('/user?ID=12345')
.then(function (response) {
// handle success
console.log(response);
})
.catch(function (error) {
// handle error
console.log(error);
})
.then(function () {
// always executed
});이 코드는 특정 URL에 GET 리퀘스트를 보내는 코드입니다. 첫 번째 줄을 import문으로 바꿔 보세요. 끝에 세미콜론도 잊지 마세요!
- 답 :
import axios from 'axios';
●이론_3_ 서브 파티 모듈 패키지의 메인 package.json 알아보기
○ default_package.json 코드 :
{
"dependencies": //"dependencies" 필드 , 필드의 값은 객체 형태로 속성명 , 속성값 둘다 문자열 형태
{
"date-fns": "^4.1.0"
}
}※ json의 필드의 값은 객체 형태로 속성명 , 속성값 둘다 문자열 형태★
○ package.json 정의 : 현재 모듈(or 패키지)에 대한 정보들이 담긴 파일
○ package.json 구성 :
- "dependencies" 필드
- 속성명 : 어떤 서브 파티 모듈이 있는지의 모듈의 이름
- 속성값 : 해당 모듈의 버전
ex_
{
"dependencies": //"dependencies" 필드 : 패키지에 들어있는 모든 서브파티 모듈의 정보가 들어있음
"date-fns": "^4.1.0" //"date-fns"이라는 모듈이 "4.1.0"의 버전으로 들어있다.
}
}※ 참고) ^의 의미 : 꼭 4.1.0 버전이 아닌 특정 범위 내의 버전이면, 괜찮다는 뜻 (어느범위까지인지는 나도몰라 시발)
- "type" 필드로 CommonJS문법이 아닌, Es모듈문법으로 작성될 수 있도록 해보기
- 위의 "dependencies"와 다르게 바로 속성값이 문자열
- "type"필드 : 어떤 JS문법이 지정되어있는지에 대한 정보 필드 //Default값 : CommonJS문법
ex_
{
"dependencies": //"dependencies" 필드 : 패키지에 들어있는 모든 서브파티 모듈의 정보가 들어있음
{
"date-fns": "^4.1.0" //"date-fns"이라는 모듈이 "4.1.0"의 버전으로 들어있다.
},
"type" : "module",
//원래는 default가 CommonJS인데, "module"을 속성값을 대입함으로써, Es문법이 가능해진다.
}- 효과 : ex로 json을 수정하면, 모든 mjs확장자를 js로 사용해도 된다.
- "scripts" 필드 : 터미널 명령어 설정 필드로, 객체 형태로 저장한다. //dependencies필드와 형식 같고, type 필드와 형식이 다르다.
ex_
{
"dependencies": //"dependencies" 필드 : 패키지에 들어있는 모든 서브파티 모듈의 정보가 들어있음
{
"date-fns": "^4.1.0" //"date-fns"이라는 모듈이 "4.1.0"의 버전으로 들어있다.
},
"type" : "module",
//원래는 default가 CommonJS인데, "module"을 속성값을 대입함으로써, Es문법이 가능해진다.
"scripts" : {
"start" : "node main.js",
//의미 : 터미널에 npm start를 입력 시, main.js로 디버깅이 되도록 설정됨
"test" : "node test.js,
//의미 : 터미널에 npm text를 입력 시, test.js로 디버깅이 되도록 설정됨
},
}※ 참고) "start", "test", "stop" ,"restart" : npm + ("run") + 명령어 ,
그 이외의 command 명령어 : npm run + 명령어 //"run"을 필수로 넣어야 한다.
●이론_3_ 참고개념 : import ... from 'date-fns' 기재할 떄, 경로가 아닌 서드파티 모듈의 이름만 써도 되는 이유 => date-fns 패키지 안에 package.json 의 "main" : "index.js" 필드 때문
"main": "index.js"라고 돼 있는데요. from 뒤에 서드파티 모듈 이름을 쓰면 서드파티 모듈의 package.json 파일을 보고 main 필드에 명시된 파일에서 import를 하는 겁니다. 이때 main 필드의 디폴트는 "index.js"이기 때문에 사실 이 필드가 없어도 잘 작동합니다.
참고로 우리가 직접 패키지를 만들 때는 이런 방식으로 import를 할 일이 거의 없고, 항상 파일 경로를 통해 import를 하면 되니까 이번 레슨의 내용은 참고만 해 두시면 좋을 것 같습니다.
●이론_4_ 전체 package의 "dependencies" 필드의 version에 대해 파헤치기 : Sementic version
● 사진에 있는 depencies 속성값에 대하여, 알아보자
- "2.29.3" : Semantic version
- Semantic version의 구성 : (캐럿기호 "^") Page version . Minor version , Petch version
Petch version :
- 버그 수정 , 코드의 효율성 등의 기존 코드에 전혀 영향을 주지 않는 업데이트 시
Minor version :
- 기능이 추가됐을 시, 업데이트 버전
Page version :
- 코드에 정말 큰 변화 , 이전 보다 호환이 안되는 업데이트 시
- Page version이 바뀔 시, 이전 버전의 모듈 사용자는 많은 부분이 수정이 필요하므로, check를 유심히 해야함
- 캐럿기호 "^" : Page version만 바뀌지 않을 시, 신경안써도 된다고 npm에게 알리는 뜻 같음
