npm, yarn
Package가 왜 생겼을까?
- Html, Css, JS 삼위일체..
- Html -> css는 style, link, tag 중 하나 이용 / js는 script or script tag 이용
- 레거시에서는 js, css 파일을 WAS에서 만드는 jsp(준 html)에 끼워넣어서 사용
- js는 순서가 중요 (인터프리터) -> 순서 꼬이면 망함
- css는 파일이 너무 많아져서 도메인 샤딩문데, 점수제/class 를 모든 페이지 마다 지정해줘서 관리해야하는 문제
- Lib에 대한 관심 증가
- CDN 방식
<script src=""></script>: CDN에서 직접 당겨서 사용함 - Bower : twitter에서 개발. CDN이 셧다운됐을 때 미러링이 안됨 = CDN 죽으면 내 사이트도 죽음. CDN에 올라와있는 library를 실제 프로젝트 폴더에 다운받아줌. package의 개념이 없고 사용자가 등록한 폴더를 통으로 다운받아줌. Bower에 등록된 코드를 통으로 받아서 서비스. lisence, copyright에 대한 개념이 적었다.
- npm : 이쯤부터 webpack이 등장.
- CDN 방식
Project
- 두 가지로 구성 : Package(npm / yarn), Bundler(webpack / snowpack / rollup ..)
- Bundler : webpack이 짱이다. snowpack은 신흥강자. esBuild(?). webpack은 완전히 마스터해야함(자유자재로 다룰 수 알아야함) 웹팩만 이해하면 다른 것들도 사용하기 쉬울것임 + babel, coreJs
Package
npm
- node 만든 애들이 만들어서.. node 설치할 때 같이 깔림
- nodejs 프로젝트의 manifasto(매니페스토는 개인이나 단체가 대중에 대하여 확고한 정치적 의도와 견해를 밝히는 것으로 연설이나 문서의 형태)가 필요하다고 생각함 = package.json
npm init실행하면 package.json 생성되는데 얘가 가장 기본의 매니페스토임- package.json에 작성된 내용을 기준으로 npm과 상호작용된다. -> npm에 퍼블리싱할 때 영향을 미치는 각 속성들 알아본다.❗️
- import 에서는 package.json를 보고 라이브러리의 파일을 적절하게 가져온다. (실제로 nodejs는 required 라는 구문을 사용함)
- package.json이 없는 기존의 link/bower는 npm과 호환이안됨. 즉, 얘네는 package가 아님
- dependencies <> dev-dependencies : nodejs 개발할 때는 조금 차이가 있으니 이해해두도록한다. 즉, 실제 차이가 나는건 서버 개발시
--productionflag를 추가한 install. - package.json은 import의 근간이다. 스펙을 정의하는 것. 이 패키지가 어떤 의존성이 있고, 어떤 파일부터 시작되는지 알 수 있다.
- lock file.. install한 시점의 버전 스냅샷.
- semver
- node version, yarn version이 다르면 lock file이 업그레이드 될 수 있음 (충돌날 수 있음)
- 누군가가 지웠다가 다시 만든 경우도 다를 수 있음..
yarn
- npm은 파일 시스템을 많이 써서 리소스 소모면에서 약점이 있었다.
- facebook이 만든 새로운 package system
- npm이 가지고 있던 고질적인 파일시스템 문제를 해결하는게 주요 목표였음
- cold build ?? zero install ??
- npm과 yarn의 발전 방향성은 약간 차이가 있음
- npm은 package system을 유지하고 있는 기본적인 시스템을 만들어낸 선구자
- npm은 빌드체인이 있어서.. 중간에 하나만 깨져도 다 터짐
- yarn이 이를 안전하게 빌드할 수 있도록 cold build에 대해 관심이 많음. 지속적으로 멱등성을 유지하려함.
- yarn beta version -> yarn2 = yarn berry
- yarn berry zero install하면 인스톨한 모든 라이브러리를 zip파일로 만들어서 git같은 곳에 올려두고 빠르게 가져올 수 있음
🤔
WAS-html + WEB-css,js 로 관리했던게 레거시
파일이 늘어가고, 정렬문제가 생기면서 library 사용이 대두되고, 이를 잘 관리하기 위해서 package manager가 나타남 -> npm이 생겨나고 프로젝트 단위로 관리되면서 Bundler를 이용.
Bundler
목표 : 기계가 js 의존성을 정의할 수 있도록 하자!!
package를 이용해서 서드파티를 관리하려고 함. 파일과 파일은 서로 연관된 트리가 있을 것. (각각은 import로 이뤄져 있음 import A from B)
🎉 import 문을 이용해서 트리구조를 만들 수 있게됨!
import A from 'react': 가장 가까운 node_modules를 찾음import A from '/react': 절대경로import A from './react': 상대경로, 현재 폴더에서 찾아올라감 -> 없으면 가장 가까운 node_modules를 찾아감. node_modules에서 찾는게 목적이면./node_modules/react로 쓰는게 더 안전하긴함. 좋은건 아님.- from절에 어떻게 들어갔냐에 따라서 특정 알고리즘에 의해 다르게 해석됨. -> nodejs의 기본룰을 따라가게 되어있음.
선후관계를 만들어 줄 때 키🗝는 import임
- 파일의 시작인 entry를 가져와서 파일의 모임인 chunk를 만들어 트리구조를 만듦
- 백그라운드에 있는 모든 것들도 webpack이 로딩을 하게 되어있음.
js나 css를 빌드 직접하는게 아니라, 웹팩을 설정함으로써 통합개발환경을 구성한다.
CRA에는 Pre-defined된 webpack이 있음.. 웹팩 설정과 디펜던시를 뒤에서 쫙 설치해준담에 얘네가 가지고 있는 프로젝트 구성을 토대로 만들어줌.
-> 웹팩만 쓸 줄 알면 넘어갈 수 있음.
*Babel.. 웹팩과 거의 한 몸임.. 없으면 개발안되는 수준.
Mono-repo
- lerna / yarn workspace
- 멀티프로젝트와 유사함. 멀티 패키지
- package.json이 루트에 있고, packages 폴더 하위에 각각 package.json을 가진 다수의 package가 있다.
- private: true인 경우 npm repository에 publishing 할 수 없음. (보통 최상위에 설정해서 껍데기는 퍼블리싱 못하게한다.)
- lerna는 cli가 아닌 javascript library라서 yarn처럼 작동하려고 learn.json이라는 설정파일이 필요함.
- workspace는 각각의 패키지를 관리하는게 주목적(통합 tool), lerna는 각 패키지에 커맨드를 날리는 목적이 더 큼(lerna를 설치하면 lerna 설정파일에 있는 커맨드를 이용해서 각 패키지에 커맨드를 날릴 수 있음)
- 퍼블리싱에는 lerna
- 매니지먼트는 workspace
- 그래서 왜 쓰냐?
- 디펜던시 정의안해도 workspaces 이용해서 자동으로 셋팅해준다!
🌱 😈💻 🌱