dependencies와 devDependencies의 구분
1. build 속도가 느리면
2. dependencies와 devDependencies의 구분
craco를 설치해서 webpack으로 커스터마이징 하는 대신
필요한 설정만 추가하려고 했다.
그런데 craco는 devDependencies에 들어가야 할까? 아니면 depenedencies에 들어가야 할까?
의문이 들었다.
개발 단계에서 필요하지만,
배포할때 굳이 필요없는 라이브러리까지 추가하게 되면
build 속도가 느려질 수 있기 때문에
두 개를 구분하는 일은 중요하다고 할 수 있다.
build가 느리면 단점이 무엇이 있을까?
build를 하고 나서 내가 작성한 코드가 잘 돌아가는지 확인을 해야 하는 작업이 있을 텐데
그걸 한참동안 기다리고 에러가 나면 다시 수정해야하고...
개발의 생산성이 매우 떨어질 것만 같다.
build 속도 개선을 위한 방법
1. dependencies와 devDependencies의 구분
2. 코드 스플리팅으로 chunk로 분리 작업
3. 느려지는 loader들 교체작업
(ex: ts-loader를 es-loader로 변경 그러나 tree-shaking이 안되는 경우를 고려 해야함 )
웹팩 환경에서의 빌드 속도 개선기 - 1
너무 느린 빌드 속도 프로젝트 개발을 하던 도중 빌드 속도가 너무 느린것을 확인하였다. development환경기준 yarn start를 할시 17초, auto save로 rebuild를 할시 7.5초가 소모 되었다. 첫 빌드속도는 크게
velog.io
[Webpack] 빌드 속도 개선
기존 React Webpack 프로젝트를 개발 서버에서 실행하면 로딩속도가 체감상 오래 걸렸다. 또한, 프로젝트의 리소스 크기가 무려 25MB로 너무 크다는 문제점도 발견하였다. 이에 대한 개선 을 위해 시
velog.io
더 생각해볼 내용
Build Performance | 웹팩
웹팩은 모듈 번들러입니다. 주요 목적은 브라우저에서 사용할 수 있도록 JavaScript 파일을 번들로 묶는 것이지만, 리소스나 애셋을 변환하고 번들링 또는 패키징할 수도 있습니다.
webpack.kr
찾아보니 webpack에서 vite로 마이그레이션 한 결과
build성능이 개선되었다는 이야기가 있었다.
그렇다면 webpack으로 커스터마이징 하는것이 아니라 이젠 vite를 사용하는 것이 맞는건 아닐까?
여전히 webpack을 사용되는 이유는 단순히 레거시의 이유만 있을까?
좀더 공부해 봐야 할 부분일 것 같다.
번들러 마이그레이션(Webpack to Vite)으로 빌드 속도 높이기
Vite는 Vue.js 팀이 개발한 웹 개발용 빌드 도구로 요즘 인기를 끌고 있습니다. 인기 비결은 뭐니해도 ‘속도’입니다. 개발과 빌드 속도가 매우 빠릅니다. Vite가 빠
tech.cloudmt.co.kr
dependencies와 devDependencies의 구분
이건 명확한 기준이 있는 부분은
개발단계에서만 필요한 typescript나 test같은 것은 devDependencies에 들어갈 수 있지만
다른 것들은 논의 중인 것 같다. 그 중 하나는 craco 인 듯 하다.
craco should actually be added to the project "dependencies", and not "devDependencies" by ndbroadbent · Pull Request #23 · di
This is because it is required for production builds, so it always needs to be present. Otherwise, if yarn install or npm install is run in an environment where NODE_ENV is set to production, it wo...
github.com
깃허브 craco 이슈에 올라온 글이다.
프로덕션 빌드에서 필요하기 때문에 craco는
devDependencies가 아닌 dependencies section에 있어야 한다는 내용이다.
This is because it is required for production builds, so it always needs to be present. Otherwise, if yarn install or npm install is run in an environment where NODE_ENV is set to production, it won't be installed and the build will fail.
This is also why react-scripts is in the "dependencies" section.
그러나 아래의 내용은 좀 다르다. 프로덕션 환경은 정적 에셋의 프리빌트 패키지가 있어야 있는데 (? 이것은 뭘까 더 찾아보자)
본인이 이해하기로는 devDependencies는 빌드타임 디펜던시이며 dependencies는 런타임을 위한 것이다.
@ndbroadbent good point but I do find it awkward to npm install or even npm run build on a production environment. Production environments should have a pre-built package of static assets. My understanding is that devDependencies are for build time dependencies and dependencies are for runtime.
그 밑의 답변은
정적 사이트에서는 s3에 전송하거나 빌드를 로컬에서 할때는 사실이다.
그러나 Heroku나 Now 등등의 툴들은 NODE_ENV가 프로덕션일때 실행한다
그래서 디펜던시에서만 기본적으로 설치된다.
@yohanb Yes that's true for static sites that you can build locally and push up to S3 or something. But if you're pushing to Heroku, Now, Flynn, Convox, etc., these tools have a build process that runs in a container where NODE_ENV is set to production, so it only installs "dependencies" by default. (And if you set it to development, then you install all the stuff you don't need like eslint and prettier.)
결국 마지막글을 3명이 따봉을 눌러주고 이슈를 닫은 것 같다.
그렇다면 craco는 일단 dependencies에 옮기는걸로....
아래는 스택오버 플로우에서 찾은 글이다
Specifying dependencies and devDependencies in a package.json file | npm Docs
Documentation for the npm registry, website, and command-line interface
docs.npmjs.com
if (your source code /src/ depends on it) {
if (you can't live without it) {
if (you don't want to affect the version that consumer choose to install) {
// This is usually for big or heavy deps, like framework level, for example: react, redux
Put it into 'peerDependencies'
} else {
// This is regular case
Put it into 'dependencies'
}
} else {
// This is a special case, means it is an optional for you in just some of the use cases.
// For example, [Swiper](https://github.com/nolimits4web/swiper), it supports react | vue | angular, but people use vue won't want to see a peerDeps of 'react', right?
Do nothing
}
} else if (only development environment depends on it) {
// This is usually used for compile and test tools.
Put it into 'devDependencies'
}