NPM

-Node Package Manager : 노드.js 프로젝트를 관리하는 필수 도구
-온라인 저장소 + 커맨드라인 도구
-package.json이라는 프로젝트 명세 파일에 따라 기능을 수행.
-서드 파티 패키지를 package registry로부터 다운 받아 개발중인 프로젝트에 사용할 수 있게 해줌
-개발중인 패키지를 npm registriy로 업로드

(1) NPM 온라인 저장소
-다양한 오픈소스 라이브러리와 도구들이 업로드되는 저장소, 필요한 라이브러리나 도구 검색 가능.

(2) 커맨드라인 도구
-프로젝트 관리를 위한 다양한 명령어 제공

• 저장소에서 라이브러리, 도구 설치
• 프로젝트 설정/관리
• 프로젝트 의존성 관리

NPM 사용

1. npm init : 프로젝트 생성

-프로젝트 디렉터리 생성 후 해당 디렉터리 안에서 명령어 사용시 질문을 통해 package.json 파일 생성, 이 디렉터리는 Node.js 프로젝트가 됨.

(1) package.json
-프로젝트 관련 정보 저장, 직접 수정 or npm 명령어를 사용하여 프로젝트 정보 수정 가능
-프로젝트에서 사용(의존)하는 서드 파티 패키지에 대한 모든 정보 저장

(2) 의존성 관리
-프로젝트 내에서 사용하는 라이브러리를 관리하는 방법.
-프로젝트의 실행은 라이브러리에 의존하므로 이러한 라이브러리들을 dependency(의존성)라고 함.

(3) 라이브러리
-특정 기능을 수행하는 코드의 묶음, 복잡한 기능을 다른 사람이 구현한 것을 가져와 사용하는 방법. Node.js에서는 package라고도 부름.

2. npm install 명령어

-프로젝트 의존성 관리 가능. 명령어는 사용 방법에 따라 요러 용도로 사용 가능.
-의존성 추가, 내려받기, 개발용 의존성 추가, 전역 패키지 추가 등

(1) npm install [package-name] : 프로젝트에 패키지 추가
-필요한 패키지를 프로젝트에 추가.
-추가된 패키지는 package.json의 dependencies 안에 추가되며 node_modules 디렉터리에 저장.

(2)npm install [package-name]@[version]으로 패키지 버전 지정 가능.
-업데이트가 지속되면 상위 버전이 하위 호환성을 지원하지 않는 경우가 있을 때 사용.

• 점으로 버전 구분
• ~1.13.0 : 물결-가장 오른쪽의 버전을 제외하고 앞에 있는 버전들을 설치 => 1.13.x 설치
• ^1.13.0 : 캐럿-가장 왼쪽의 0이 아닌 버전을 고정하고 설치 => 1.x.x 버전 설치
• 0.13.0 : 0.13.0 버전만 설치

(3) npm install [package-name] --save-dev : 개발용 의존성 추가
-npm은 개발용 의존성을 분리하여 관리 가능.

• 개발용 의존성 : 배포 전까지만 사용하는 의존성(ex. 유닛 테스트 라이브러리)

-'--save-dev'옵션을 이용하여 개발용 의존성 추가
-개발용 의존성은 package.json > devDependecies에 추가됨

(4) npm install : 프로젝트에 의존성/개발용 의존성 내려받기
-npm install 명렁어를 옵션 없이 사용시 package.json에 정의된 dependencies와 devDependencies의 의존성을 node_moudles 디렉터리에 내려받음.
-기본적으로 node_modules 디렉터리는 코드 관리나 배포시에 업로드 하지 않는다. 의존성이 많아지면 용량이 너무 커지고 운영체제별로 실행되는 코드가 다른 경우가 존재하기 때문.

(5) npm install --production : 프로젝트에 개발용 의존성을 제외하고 내려받기
-배포시 개발용 의존성 포함할 필요 없음.
-package.json의 dependencies만 node_modules에 내려받음.

(6) package-lock.json
-프로젝트에 의존성 추가시 생성되는 파일.
-프로젝트에 의존성을 추가하면 자동으로 '^최신버전'형태로 추가가 되는데 의존성 버전이 갑자기 변경되지 않도록 설치된 버전을 고정하는 역할을 함.

(7) npm install [package-name] --global : 전역 패키지 추가
-패키지를 '전역 패키지 디렉터리'에 내려받음
-'커맨드라인 도구'들을 주로 전역 패키지로 추가해서 사용
-ex) 웹서버를 만들어주는 express-generator 혹은 node.js 프로세서를 관리하는 pm2 등.
-프로젝트 외부에서 사용하는 패키지를 내려받을 수 있음.

1) 로컬 패키지
-package.json에 선언되어 있고 node_modules에 저장된 패키지

2) 전역 패키지
-npm install -g를 통해 내려받아 전역 패키지 저장소에 저장된 패키지
-전역 패키지도 프로젝트에서 사용 가능하나 '프로젝트의 의존성이 package.json 내에 명시적으로 선언되어 있는 것이 프로젝트 관리에 좋다.

(8) npm remove [package-name] : 의존성 삭제
-의존성 패키지를 삭제
-package.json의 dependencies/devDependencies에서 삭제하고 node_modules에서도 제거

(9) npm run [script-name] : 스크립트 실행
-스크립트 : 간단한 동작을 수행하는 코드
-package.json의 scripts에 선언된 스크립트를 실행

//package.json
{
...
"scripts" : {
	"say": "echo \"hi"\ "
    },
...
}

//실행
$ npm run say
"hi"

1) npm script 사용 이유
-npm script 내에선 의존성 패키지를 바로 사용할 수 있음
-node_modules에서 다운 받아 사용하는게 아니라 직접 호출 가능함.
"scripts" : {"test": "node_moduels/.bin/tap test/\*.js"}
=>
"scripts" : {"test" : "tap test"/\*.

2) 자주 사용되는 스크립트
-run을 제외하고 사용할 수 있는 주요 스크립트들은 다음과 같으나 run을 제외하고 사용할 수 있을 뿐 npm 내부적으로 코드를 제공해 주는 것은 아님.
-npm test [script-name] : 코드 유닛 테스트 등에 사용
-npm start [script-name] : 프로젝트 실행
-npm stop [script-name] : 프로젝트 종료

3. package.json & package-lock.json

(1) package.json
-현재 프로젝트에 대한 메타데이터 및 npm script 그리고 사용(의존)하고 있는 외부(서드 파티) 모듈을 정리한 파일
-이 파일이 없어도 Node.js를 사용해서 Js파일을 실행시킬 순 있으나 package.json이 없으면 서드 파티 패키지(라이브러리)를 Js에서 import/require해서 사용할 수가 없음.
-git repository에 올린 프로젝트를 다른 컴퓨터에서 받아서 개발을 할 때 원래 작업했던 컴퓨터와 같은 프로젝트 상태로 구성하기 위해서임. 이 파일이 없으면 현재 프로젝트가 어떤 라이브러리를 쓰는지를 바로 알 수가 없음
-일종의 배송 명세서

(2) package-lock.json
-package.json에 기록된 내용을 새로운 npm install이 발생할 때마다 snapshot 형태(그 순간의 상태)로 생성하는 파일.
-사용하고 있는 외부 모듈들의 상세한 스펙들이 저장되어 있다. npm은 이 파일을 이용해서
현재 프로젝트가 정확히 어떤 버전의 어떤 모듈들(그리고 그 모듈이 사용하고 있는 의존 모듈의 버전들까지)을 사용하고 있는지를 판단하여 install할 수 있게 된다.
-이 파일이 없으면 프로젝트를 클론 받고 npm install 진행시 프로젝트 팀원과 다른 버전의 모듈들을 설치할 수도 있다
-실제 프로젝트에서 사용하는 서드파티 패키지에 대한 정확한 정보를 가지고 있음.
서드파티 패키지의 지문 역할을 하는 integrity값을 가지고 있는데 이는 해당 패키지를 다시 다운 받을 때 내가 이전에 받았던 패키지와 지금 받으려는 패키지가 동일한 지 체크를 위한 값임. 정품 인증과 비슷.

(3) dependencies: 어플리케이션 코드에 직접적으로 사용되는 모듈들

(4) devDependencies: 어플리케이션 코드에는 사용되지 않지만 테스트/프로세스 재시작/린팅 작업들을 수행할 때 사용되는 모듈들. 간단하게 말하면 서포트 툴

외부 모듈들이 설치되는 node_modules 경로는 항상 git의 트래킹에서 제외하자. 사이즈가 너무 크고 어차피 package-lock.json이 있어서 괜찮다.

4. npm Registry
   -패키지를 업로드하는 공간
   -Public/Private
   -개발자들은 registry로부터 필요한 서드파티 패키지를 받아 본인 코드에서 사용 가능
   -회사 내부에서만 사용하는 패키지는 private registry로 사용
   -NPM(inc.), GitHub Package Registry, JFrog, GitLab Package Registry
   -소스 코드 자체를 관리하는 git repository와는 다름, 완성된 제품을 저장하는 저장소에 가깝다.
   -일종의 물류센터

5. 요약
   

서버

-클라이언트의 요청에 응답

1. 클라이언트-서버 구조(Client-Server Architecture)
   
   -클라이언트는 요청하는 머신의 프로세스, 서버는 응답을 하는 머신의 프로세스

-클라이언트와 서버는 '주소'가 있어야 통신이 가능 - 주소는 보통 IP 또는 Domain 사용.

-요청과 요청 처리 응답까지의 과정을 Transaction이라 한다.

-서버 개발 : 요청과 응답 사이에 로직을 더하는 행위

-프로토콜 : 데이터 교환을 위한 규약.
-데이터는 지원하는 포맷에 따라 다양하게 제공 가능.

-클라이언트 !=== 브라우저. 클라이언트(프론트)는 또 다른 서버가 될 수도 있다.

-하나의 서버 머신 안에 여러 개의 서버 프로세스(웹 서버, 웹 어플리케이션 서버)가 존재 가능.
-각 서버 프로세스가 자신만의 요청을 수신할 수 있는 방법 : 포트(Port : 개발자가 지정)
-크게 볼 때 하나의 주소(IP)지만 포트와 조합해서 서버 프로세스를 구분 가능.
-아파트처럼 같은 동 주민들은 한 동(IP)에 속하지만 호수(Port)로 각자의 주소를 갖는다.

2. 서버의 장점
   -다수의 사용자의 데이터를 중앙(!== 하나의 서버)에서 처리하여 데이터의 일관성(정확성) 및 데이터 관리 유지 용이
   -상대적으로 빠른 연산이 필요한 작업들을 성능이 좋은 중앙 서버에 위임 가능. 클라이언트 머신의 성능이 크게 중요하지 않다. 비동기 작업 가능.
   -클라이언트로부터 중요한 비즈니스 로직 코드를 숨길 수 있음.

3. 서버의 단점
   -Single point of failure(SPOF) 서버가 다운되면 서비스가 돌아가지 않는다.
   -요청의 양이 많아질수록 서버에 부하가 심해진다.

• 서버 수직 확장(Scale up) or 수평 확장(Scale out)이 필요해진다. 즉 비용 증가.

-데이터 중앙관리 = 공격자들의 공격에 취약
-서버 유지 보수 비용 발생

4. 웹 서버
   -정적 컨텐츠를 제공하기 위한 서버(HTML, JS, CSS, 이미지...) 프로그램
   -HTTP 요청을 다루도록 설계
   -클라이언트는 주로 웹 브라우저
   -자주 업데이트 되지 않는 페이지들에 적합.
   -Node.js는 빌트인 HTTP 서버 모듈이 있어 웹 서버 역할 가능.

5. 웹 어플리케이션 서버(WAS)
   -동적 데이터를 제공
   -클라이언트에게 정적 컨텐츠가 아닌 '서비스(비지니스 로직)'를 제공할 수 있는 서버
   -주로 웹 개발 분야에서의 백엔드 개발은 WAS 코드 개발을 의미. 하지만 웹 서비스는 단순히 WAS로만 이루어지지 않으므로 웹 서버에 대해서도 이해하고 다룰 줄 알아야 함.

6. 통신 프로토콜

(1) BE가 자주 접하는 프로토콜-OSI 7계층의 Application Layer 기준

1) HTTP/HTTPS : 문서라 쓰고 Hypertext라 읽음
2) SSH : 원격 머신에 접속 및 제어
3) FTP/SFTP : 파일전송
4) WebSocket : Full-duplex(전이) 통신
5) DNS : human-readable 도메인을 IP(machine frinedly address)로 변환
6) SMTP & IMAP/POP3 : 메일 전송, 메일 서버 복사, 메일 서버 동기화
7) DHCP : 네트워크에 연결된 머신들에 IP 할당
8) MQTT : 경량 machine-to-machine(M2M) 통신, 메시지 큐(브로커, 클라이언트)형식으로 통신이 가능(Diagram)

7. HTTP
   -가장 많이 사용하는 포로토콜 중 하나로 브라우저의 기본 프로토콜.
   -HTTP 프로토콜을 이용한 통신은 크게 요청(Request)와 응답(Response)로 나눠지며 공통적으로 HTTP Header/Body 구조를 가진다.
   -가장 많이 사용되는 버전은 HTTP/1.1 이지만 현재 HTTP/3까지 개발 (차이점?)
   -POST/GET/PUT/DELETE라는 method들을 지원하는데 CRUD 작업과 1:1 매핑을 시켜서 직관적으로 URL을 사용해서 서버에 작업을 시킬 수 있다.
   -OSI 7 계층의 L7(최상위)이다.
   

8. Node.js 서버 예제의 HTTP 통신
   (1) Stream
   -데이터 흐름(연속성)을 추상화
   -배열, 문자열과 비슷한 데이터의 컬렉션, 다만 배열/문자열과 다른 점은 담고자 하는 데이터가 개발자가 원하는 시점에 반드시 담기지는 않는다는 점, 그리고 매우 큰 규모의 데이터를 다룰 수 있다는 점이다
   -데이터를 덩어리로 쪼개서(chunk라고도 함) 하나 씩 읽고 해당 덩어리에 대해 작업을 수행할 수 있도록 하여준다
   -다루고자 하는 데이터가 Node.js 상에서 바로 준비될 수 없을 때 사용을 많이한다
   -Web Stream과는 다른 스펙

(2) Node.js 서버 내부 데이터 흐름

NPX

(1) 개요
-npm 패키지를 설치 없이 사용할 수 있게 해주는 도구, 프로젝트에 추가하거나 전역 패키지로 추가하지 않고 npx를 이용하여 바로 실행 가능함
-자주 사용하지 않으나 한번씩 사용하는 npm 패키지는 npx로 쉽게 사용 가능.

//npm
$ npm i cowsay -g
$ cowsay hi

//npx
$ npx cowsay hi

(2) node.js 특정 버전 실행 가능
-npx를 사용하면 node.js의 특정 버전을 따로 설치하지 않고 바로 사용할 수 있음(js파일 실행 가능)
-프로젝트의 node.js 버전 별 실행 환경을 확인할 때 유용

$ npx node@12 index.js
$ npx node@14 index.js

(3) github gist 코드 실행
-gist : github에 등록된 간단한 코드
-npx를 이용하면 gist를 다운받지 않고 바로 실행 가능
-git이 설치되어 있어야 하고 온라인상 코드는 위험성을 내포하므로 코드를 잘 확인하고 실행해야함.

//gist
$ npx https://gist.github.com~~~~~~~~~

Node.js의 모듈

1. 모듈

-프로젝트가 커지면 기능에 맞게 코드를 분리하는 것이 중요, 모듈은 코드를 분리하기 위한 방법.

-반복되는 B라는 코드를 모듈로 분리하여 사용.
(1) 모듈과 패키지
-패키지는 모듈의 모음집.
-npm 패키지들은 많은 모듈을 포함하고 있는 코드 모음.

(2) 기본 제공 모듈
1) console
-브라우저 console과 유사한 디버깅 도구
-log, warn, error 함수로 '로그 레벨' 표시
-time, timeLog, timeEnd 함수로 '시간 추적'

2) process
-현재 실행프로세스 관련 기능 제공
-arch, argv, env 등 '실행 환경 및 변수' 관련 값 제공
-abort, kill, exit 등 '프로세스 동작'관련 함수 제공

3) fs
-'파일 입출력'을 위해 사용
-readFile, writeFile 함수로 '파일 읽기/쓰기'
-Sync 함수 제공, readFily-Sync / writeFiel-Sync로 '동기적 동작' 가능
-watch로 '파일/디렉터리 변경 이벤트 감지, 콜백 실행'

4) http
-http 서버, 클라이언트를 위해 사용
-createServer 함수로 '서버 생성'
-Request 함수로 'http 요청 생성'

5) 기타 기본 제공 모듈
-url : url파싱
-os : 운영체제 정보 -cpu, memory, type///
-Path : 디렉터리 string 관련작업 - 서로 다른 운영체제 간 공통된 로직
-crypto : 암호화, hash 관련 함수 제공

2. 모듈 작성과 사용

(1) 모듈 작성
-'modules.exports' 사용
-모듈의 구조 : Module 의 exports 객체에 우리가 추출할 값을 할당
-따라서 module.exports 를 사용하면 이 exports키에 추출할 함수들을 객체 자체로 할당해 추출할 수 있다

require
-결국에는 module.exports 한 결과물을 반환한다.
-따라서 module.exports 를 써도, exports를 써도, module.exports 를 반환해야한다.
-require 는 Node.js에서 사용되고 있는 CommonJS (node.js의 모듈시스템) 키워드

var require = function(path) {
// ...
return module.exports;
};

module.exports

Module {
id: '.',
path: '/',
exports: {},
filename: '/app.js',
loaded: false,
children: [],
paths: [
'/Users/node_modules',
'/node_modules'
]
}

exports

-exports 를 사용해도 위의 Module 의 exports 키에 추출할 값을 할당한다. 이때에는 기존의 Module 의 exports 키 객체에 프로퍼티로 할당하게된다.
1) 즉, 아래와 같이 exports 키 객체에 객체 자체를 할당하는 경우는 올바르게 추출되지 않는다.

// app.js
var myModule = (number) => {
return number * 2;
}
exports = myModule;

// check.js
var check = require('./app.js');
console.log(check(2));
// 결과
// {}

2)아래와 같이 exports 키 객체에 프로퍼티로 객체를 할당하는 경우에는 올바르게 추출된다.

// app.js
var myModule = (number) => {
return number * 2;
}
exports.myModule = myModule; //exports.myModule 처럼 키 프로퍼티로 할당해야함
// check.js
var check = require('./app.js');
console.log(check.myModule(2)); //check.myModule로 찍어야 함.
// 결과
// 4

1) 기본 형태
-값을 정해서 module.exports 의 객체 형태로 내보냄
-모듈이 load 될 때 사용할 값을 module.exports로 내보냄

//who.js
const name = 'kim';
const age = 18;
const country = 'korea';
//모듈이 load 될 때 사용할 값을 module.exports로 내보냄
module.exports = {
  name,
  age,
  country,
};

---
const student = require('./who.js');
//student 출력값 {name: 'kim', age : 18, country: 'korea'}

2) 변수명으로 export
-값을 정해서 모듈을 obj로 만들고 각 key-value를 지정해서 내보냄
-exports.변수명 = key값; 형태로 내보냄.

//who.js
const name = 'kim';
const age = 18;
const country = 'korea';
//모듈이 load 될 때 사용할 값을 exports.변수명 = key 값으로 내보냄.
exports.이름 = name;
exports.나이 = age;
exports.국적 = country;

---
const student = require('./who.js');
//student 출력값 {이름: 'kim', 나이 : 18, 국적: 'korea'}

3) 함수 export
-모듈을 함수로 만들어서 모듈 사용 시에 값을 정할 수 있게 내보냄
-클래스나 함수 내보낼 때 끝에 세미콜론 생략해야함.
-함수 모듈을 require하여 사용할 때에는 myFunc()와 같이 중괄호를 사용해주어야 함.
ⓐ

//who.js
module.exports = (name, age, country) =>{
  return {
    name,
    age,
    country,
  };
}

---
const student = require('./who.js');
//student 출력값 {name: 'kim', age : 18, country: 'korea'}

ⓑ 실행시 콘솔에 숫자가 1~10까지 찍히게 만들기.

//counter.js
let count = 0;

module.exports = count += 1;

const counter = require('./counter');
//index.js
for (let i = 0; i < 10; i++) {
    console.log(counter);
}
//결과값 : 1 만 10개가 찍힘.
---
  //수정 후

//counter.js
let count = 0;

module.exports = () =>{
  return  count += 1;
}
//index.js
const counter = require('./counter');

for (let i = 0; i < 10; i++) {
  //중괄호 사용해서 실행
    console.log(counter());
}

(2) require가 모듈을 가져오는 기준
-Node.js는 require()에 지정한 값이 Core module이 아니고, ‘/’ , ’../’ , ‘./’ 으로 시작하지 않는다면, 서드파티 모듈을 찾는다.
-require를 요청한 경로를 기준으로 node_modules에서 해당 모듈을 찾을 때까지 점점 깊게 탐색한다.

//1. exports를 import해서 변수 getSquare에 할당.
const getSquare = require('./exports.js');
console.log(getSquare.area(5));
console.log(getSquare.perimeter(5));
//2. module_exports를 import해서 변수 getSquare2에 할당.
const getSquare2 = require('./module_exports.js');
console.log(getSquare2.area(3));
console.log(getSquare2.perimeter(3));

//exports.js
//정사각형의 넓이와 둘레를 구하는 함수를 모듈로 생성. 이때 exports에 각 함수를 할당.
exports.area = width => Math.pow(width, 2);
exports.perimeter = width => width * 4;

// module_exports.js
//1. module.exports는 개별 함수가 아닌 객체를 통째로 exports할 때 사용. exports.js와 같은 정사각형의 넓이와 둘레를 구하는 함수를 모듈을 생성.
module.exports = {
area: width => Math.pow(width, 2),
perimeter: width => width * 4,
};

ex)현재 경로가 '/home/ry/projects/foo.js’ 이고, require('bar.js') 를 호출하였다.
-Node.js는 bar.js를 찾기 위해 아래의 순서로 node_modules에서 bar.js를 탐색한다.
1./home/ry/projects/node_modules/bar.js
2./home/ry/node_modules/bar.js
3./home/node_modules/bar.js
4./node_modules/bar.js

(3) 모듈 사용
-require 함수를 통해 모듈을 불러옴 : require시 모듈 코드가 실행됨
-의존성 패키지, 직접 작성한 모듈 사용 가능
-Node.js의 모듈은 첫 require 시에 cache 되어 두 번 실행하지 않음
-다른 파일에서 같은 모듈 require 하려면 모듈 코드를 여러 번 실행하기 위해선 함수 모듈로 작성.

1) npm 패키지

const dayjs = require('dayjs');

console.log(dayjs());

-의존성 패키지들은 require('package-name') 형태로 load할 수 있음
-패키지를 사용하려면 node_modules에 내려받아져 있어야 함

• package.json의 dependencies/dev-Dependencies에 정의되어 있어도 node_module에 없다면 require시 오류 발생.

2) 직접 작성한 모듈

//module1.js
module.exports = "module1";
//동일 디렉토리 다른 폴더의 module2.js
module.exports = "module2";

//index.js
const module1 = require('./module1');
const module2 = require('./module2');

conosle.log(module1, module2);

-직접 작성한 모듈은 '현재 작성중인 파일과의 상대 디렉터리'로 load
-my-module이 .js 파일인 경우 해당 파일 load
-my-module이 디렉터리인 경우 디렉터리 내의 js파일 load

• my-module/index.js

-폴더명 만으로 index.js가 불러와진 이유 : 서순 정해져있음.
폴더/package.json → 폴더/index.js → 폴더/index.json → 폴더/index.node 순으로 탐색하여 존재하면 가져옴.

3) 함수형 모듈
-함수 모듈을 require하여 사용할 때에는 myFunc()와 같이 중괄호를 사용해주어야 함.

//functionModule.js
module.exports = () => "funcModule";
//index.js
const funcModule = require('./my-function-module');

console.log(funcModule(name, age, country));

-함수형 모듈은 load한 경우 모듈이 바로 실행되지 않음 : 기존 require와 다름
-필요한 시점에 load된 함수를 실행하여 모듈을 사용할 수 있음

4) 요약
-moduel.exports를 사용하여 모듈 작성 가능
-require를 사용하여 의존성 패키지, 모듈, json 파일 사용 가능
-모듈은 첫 require 시에만 실행하고 cache 되므로 여러번 실행할 모듈은 함수형으로 작성.

3. ES Module

-ES6에서 등장한 Js의 공식적인 표준 모듈
-Js는 기본적으로 '모듈'을 제공하고 있지 않았음
-Node.js는 독자적인 방식을 통해 모듈을 지원하고 있었음 : commonjs
-ES Module의 등장으로 Node.js에선 두 가지 모듈을 지원할 필요가 생김

(1) ES Module vs commonjs
-ES Module과 commonjs는 문법과 기본적인 동작 방식이 다름

• commonjs : module.exports와 require로 모듈을 만들고 사용
• ES Module은 export와 import로 모듈을 만들고 사용

-ES 모듈은 Node.js에서 기본적으로 사용시 제약이 많음

• 프로젝트 타입을 module로 변경, commonjs 모듈 import 시에 문제 발생 등..