# esbuild

jerrychu

번들러 연대기 Vite가 기존 다른 번들러와 비교해 어떻게 빠를 수 있는 것인지 이해하기 위해 먼저 번들러의 역사를 알아보자. 간단한 동작을 하기 위한 언어로 만들어졌기 때문에 모듈이 존재하지 않다는 것은 큰 프로그램을 만드는 것이 어렵다는 것이다. 그리고 Node가 생기면서 서버에서 js 사용이 가능했다. require, module.export를 사용하는 CommonJS 모듈 방식이 생겼다. 이후 가 가능하게 됐다. 하지만 브라우저에서 module의 사용은 여러 파일을 동시에 호출하게 되면 가 있었다. 이 문제를 해결하기 위해 하였다. 여러 파일을 비동기적으로 로딩하는 것이 문제이기 때문에 파일을 하나로 합쳐 번들로 만들어 브라우저에 전달하는 번들러가 등장한다. 여기서 이 생기는데 번들링 과정이 추가되면서 코드를 수정할 때마다 매번 빌드를 다시 했고 이 속도가 빠르지 않기 때문에 코드를 수정하면 빠르게 변경이 되지 않았다. ![esbuild](https://vel

s2ksh77

최근 사업건 회고 최근 들어온 사업 중에 어드민 모듈을 맡게 되었습니다. 기존에 webpack으로 구성하던 프로젝트들과 별개로 The State of JS에서 봐왔던 vite라는 번들러의 esbuild 에 대해 경험해보자라는 의견을 내게 되었고 vite 환경으로 구성하게 되었습니다. vite 프로젝트 구성 사실 많은 글들에서도 보았듯이 vite 프로젝트를 구성하기에는 cra 만큼이나 명령어만으로도 쉽게 구성할 수 있었습니다. (생략) vite를 사용해보며 느낀 간단한 장단점 Vite Vue 창시자 Evan You가 만든 새로운 프론트엔드 도구로 프랑스어로 "빠르다(Quick)"를 의미하며 빠르고 간결한 모던 웹 프로젝트 개발 경험에 초점을 맞춰 탄생한 빌드 도구 입니다. [장점] 정말 빠르다고 느꼈습니다. 위에서 설명한 만큼 실제 사용했을 때 정말 말도 안되는 속도로 느껴지면서 "뭐야, 벌써 빌드가 되었어?" 라는 느낌이 들었습니다. r

just-do-justin

스타일링 라이브러리 Emotion Emotion은 JavaScript를 사용하여 CSS 스타일을 관리하는 라이브러리로, React와 다른 프레임워크에서 사용할 수 있습니다. Emotion은 CSS-in-JS 스타일링 방식을 채택하여, 컴포넌트와 함께 스타일을 선언하고 적용할 수 있습니다. CSS-in-JS 방식 중 하나인 "Styled Components"와 유사한 기능을 제공합니다. CSS-in-JS: Emotion은 JavaScript 코드 안에서 CSS 스타일을 작성할 수 있도록 해주는 방식으로, 스타일과 컴포넌트를 함께 관리할 수 있습니다. 퍼포먼스: Emotion은 빠른 런타임 성능을 제공하며, 스타일을 최적화하여 불필요한 렌더링을 방지합니다. 스타일 재사용: Emotion은 스타일을 JavaScript 객체로 추상화하여 재사용성을 높여줍니다. Framer-motion Framer Motion은 모션 그래픽 및 애니메이션을 구현하기 위한

badbeoti

저번 달 작성한 토스ㅣSLASH 23 - 달리는 토스 앱에 React Native 엔진 더하기 글이 SEO의 선택을 받은 것일까 조회수가 꽤 잘 오르고 있다. 하지만 최근 인터뷰에서 해당 글과 관련한 질문에 대답이 미흡해서 아쉬웠다. 질문은 esbuild와 관련된 내용이었고, 기존 metro 번들러와 차이점, 속도가 더 빠른 이유에 대해 물어봤었다. esbuild로 react-native 프로젝트를 빌드하는 것이 막연히 복잡하고 어려운 사항이라 생각해 디테일하게 공부하지 않은 점이 화근이었다. ![](https://velog.velcdn.com/images/badbeo

teihong93

발단 사이드 프로젝트를 3명이서 진행하고 있는데, 일정을 관리(독촉)해주고 해당 주차 작업을 제대로 진행하지 않은 멤버에게 커피 구매권을 누적하는 봇이 있으면 좋겠다고 생각했다. 그래서 디스코드 봇을 만드는 방법을 찾아보던 중, 타입스크립트로 만드는 자료는 거의 없고, discord.js 문서는 뭔가 편안하게 읽히지 않으며 찾은 자료들은 2~3년은 지난듯한 코드밖에 없어 겸사겸사 정리해 보았다. (공식 가이드) "module.export요? MZ 하지 않군요" https://discordjs.guide/creating-your-bot/slash-commands.html#individual-command-files 사용 라이브러리 yarn berry esbuild (배포할때 도커 말아줄려고) discord.js typescript 봇 만들기 먼저, 디스코드 채널은 이미 생성되어있고, 권한을 가진 BOT 토큰도 이미 발급받았다는 전제

gygy

이번 포스팅에서는... 실무에서 Vite migration을 진행하면서 알아본 내용을 간략히 정리합니다. 간략한 번들링의 역사 Vite가 등장한 배경 Vite의 장점 Vite와 번들링의 역사 자바스크립트는 모듈이 없었다 태초의 자바스크립트는 웹 애플리케이션을 만들기 위한 목적으로 만들어지지 않았기 때문에 파일을 여러 개로 분리해 개발할 수조차 없었습니다. 그 말은 즉, 대규모 프로젝트를 진행할 수 없다는 의미이기도 합니다. 하나의 파일에서 동시에 여러 개발자가 여러 기능을 위한 코드를 추가하며 깃으로 협업할 수는 없으니까요..! Node의 탄생으로 모듈을 사용하기 시작 node가 탄생하면서 서버에서 자바스크립트를 사용할 수 있게 되었죠. 이 떄 commonJS방식의 'module'이 만들어집니다. 또한 npm의 등장으로 만들어진 모듈을 모두가 공유할 수 있었고, 이 때부터 자바스크립트에서 본격적으로 모듈이 활용되기 시작합니다. 브라우

jinic

Vite 처음에는 Vue를 위해 만들어졌으나 지금은 React 등 다른 프레임워크와 라이브러리에도 지원 가능 https://github.com/vitejs/awesome-vite https://velog.io/@wynter_j/Bundler-JavaScript-%EB%B2%88%EB%93%A4%EB%9F%AC-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Webpack-Parcel-Rollup-Vite...-2 Vite 플러그인은 기본적으로 현재 빌드 또는 개발 환경에서 사용되는 파일에 대해서만 변환 작업을 수행합니다. 따라서 호출되지 않는 저장소 내 파일은 Vite 플러그인 내에서 직접적으로 변환할 수는 없습니다. Vite 플러그인은 빌드 또는 개발 서버 실행 시에만 작동하며, 플러그인 내에서 파일을 변환하는 작업은 플러그인의 transform 함수 내에서 수행됩니다. 이 함수는 현재 처리 중인 파일에 대해 호출됩니다. 호출되지 않는 파일에 대한 변환 작업을 수

goyoung2

인사 안녕하세요~👋 고영이에요. 오늘은 정말 정말 빠른 번들러인 Vite(비트)를 소개하려고 해요. 번들러 SPA 등의 라이브러리나 프레임워크를 쓰다보면 제품 성능과 파일 관리를 위해 웹 번들러를 사용하게 되는데요. 가장 보편적으로 webpack을 많이 사용하지만 webpack의 단점인 속도가 느리고 설정이 어렵다는 문제로 parcel, rollup 등의 번들러를 사용하기도 해요. 그러다가 혜성처럼 나타난 Vite가 가파르게 점유율을 차지하고 있는 상황이에요. Vite가 뭐죠? Vite는 프런트엔드 개발 경험을 크게 향상시키는 새로운 유형의 프런트엔드 빌드 도구에요. Esbuild를 사용하여 기존 빌더 대비 10~100배의 아주 빠른 속도를 내며, 간단한 설정만으로 손쉽게 동작해요. Vite를 사용해야하는 이유(공식문서): https://vitejs-kr.github.io/guide/why.html#the-problems Vite가 빠른 이유

gwak2837

상황 해결 .yarnrc.yml packageExtensions에 pg 추가하기

projaguar

Intro 이전 블로그에서 yarn berry workspace를 이용하여, NextJS, Nest, React Native 와 공유 라이브러리에 대해 정리하였습니다. 그 내용을 바탕으로 프로젝트를 진행하면서, 추가할 내용과 조금 더 설명되어야 할 부분들이 생겨 조금 더 상세하게 연재하도록 하겠습니다. 목표 가급적 최소한의 설정. NextJS, Nest, React Native 모두를 포함할 수 있는 설정 이번 블로그에서는 yarn berry workspace의 기본적인 설정을 진행 하겠습니다. 주요 내용 yarn workspace 생성 typescript 설정 eslint / prettier 설정 jest 설정 수정 2023.07.06 - eslint prettier

gwak2837

Fastify 백엔드 서버를 구성해봅시다. Yarn berry > https://yarnpkg.com/getting-started/install Git > https://www.toptal.com/developers/gitignore .gitignore 파일을 생성하고 적절히 수정합니다. .gitattributes 파일을 아래와 같이 생성합니다: package.json > https://docs.npmjs.com/cli/v8/configuring-npm/package-json package.json 파일을 수정합니다: TypeScript > https://www.typescriptlang.org/download \ > https://stackoverflow.com/questions/72380007/what-typescript-configuration-produces-output-closest-to-node-js-1

youngkiu

CLI https://dev.to/endel/nodejs-package-authors-please-support-both-cjs-and-esm-1oj3 Scripts https://github.com/youngkiu/schema-to-erd/blob/main/build.js package.json 참고) https://antfu.me/posts/publish-esm-and-cjs https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1

tkmoon1020

Webpack5로 사이드 프로젝트를 시작하였다. 필자에게 가장 익숙한 uglifyjs-webpack-plugin을 사용하려 했으나, webpack4까지만 uglify-js를 사용하고, webpack5 부터는 es6를 지원하지 않는다는 이유로 terser로 교체되었다고 한다. 1. Minifier 비교 가장 효율적인 방법을 찾기 위해 Minifier 벤치마크 결과를 찾아보았다. 관련 링크 webpack4와 webpack5의 플러그인인 uglifyjs와 terser를 비교해 보았다. React v17.0.2 Original Size: 72.14kB를 각각의 Minifier로 압축했을 경우 결과는 아래와 같다. |--------|Minified Size| Time| |:------:|------------:|----

bard

시작한 계기 > RisingStars 에서 Esbuild 를 접하고 흥미가 생겼다 > RisingStars 프로젝트 시작 프로젝트 파일 생성 프로젝트 파일 생성 yarn 버전 변경 packageManager 초기화 esbuild 번들러 추가 의존성 추가 개발 의존성 추가 tsc 초기화 index.html 추가 ` ind

goon126

오랜만의 포스팅입니다 :) 이번에는 저희 프로젝트에서 빌드성능 개선한 후기를 포스팅 하려 합니다. 항상 말씀드리지만 가이드 같은것들은 워낙 좋은 글 들이 많아서 그걸 보시면 될것 같고 저는 실무를 하면서 겪을 수 있는 어려운 이슈에 대한 경험 및 고도화 위주로 포스팅 하려고 노력하는데요. 이번 빌드성능 개선 건은 정말.. 이미 크게 서비스되고 있는 환경에서 환경개선을 하려다 보니 고생을 너무 많이 한것 같네요 😥 자 그럼 시작합니다. 1. 빌드환경 개선의 필요성 처음에는 다들 그렇듯 작은 서비스로 시작하였습니다. 솔직히 이정도의 서비스까지 커질줄 몰랐는데 점점 런칭되는 서비스가 늘어나고 입점과 동시에 개편과 개선을 진행하면서 프로젝트가 상당히 거대해졌습니다. 그러다보니 지난번 [청크파일 분리](https://velog.io/@goon126/%EB%A6%AC%EC%95%A1%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%8A%A4%ED%94%8

yrnana

https://yrnana.dev/post/2021-05-26-webpack-vite 이런 제목을 어디서 본 것 같은데? 라고 생각한다면 정상이다. > https://yrnana.dev/post/2021-02-11-webpack-snowpack Vite는 Snowpack과 아주 유사한 컨셉의 프론트엔드 빌드툴이다. Vue.js의 창시자로 유명한 Evan You가 개발했고 이름값을 하는 것 같다. SvelteKit도 Snowpack을 손절하고 Vite로 갈아탄 듯 하다 (웃픈...) SvelteKit에서 설명하는 Vite의 비교장점은 Snowpack보다 SSR을 더 잘 지원한다는 점이다. 내가 느낀 장점은 Snowpack은 chrome devtools에 tsc와 esbuild로 이미 빌드가 된 상태의 js 파일을 보여줘서 source탭을 무용지물로 만드는 반면 Vite는 소스맵을 잘 지원한다는 점이다. 그러니까 사이드 프로젝트에는

yrnana

https://yrnana.dev/post/2021-02-11-webpack-snowpack > 🚨 Update > https://yrnana.dev/post/2021-05-26-webpack-vite > Snowpack과 유사한 컨셉의 Vite를 추천하는 이유 Snowpack 스노우팩은 unbundled during development 즉 개발중에 번들링을 하지 않겠다는 컨셉의 프론트엔트 빌드툴이다. Unbundled Development 예를들면 현재 빌드툴로 가장 많이 사용되는 webpack 같은 경우, 파일 하나가 변경될 경우 연관된 모든 파일을 다시 빌드하고 다시 번들링 해야 한다. 그래서 시간 복잡도를 O(n) 으로 가져가야 한다. 스노우팩은 개발중에 모든 파일들

lingodingo

사내에서 발표했던 것을 정리한 내용이다 개발자는 코드를 수정하자마자 바로 반영되기를 원한다. 하지만 그 시간 차가 20분 정도 난다고 하면 얼마나 짜증이 날까..? 이 시리즈는 배포 속도를 최대한 끌어올려 본 경험을 정리한 것이다. 😎 현재 배포 환경 보통 프론트엔드에서의 배포라고 함이라면, master에 머지 (PR이든 직접 Push든) CI에서 해당 레포가 머지됬단 걸 확인 인스턴스(VM) 부팅, 리눅스 및 노드 설치, 레포내의 코드 옮겨오기 패키지 설치 package.json에 설정되어 있는 커맨드를 통해 번들러(Webpack)를 실행하여 빌드 시작 결과물을 S3에 파일 업로드 위의 작업을 실행하는데 현재 7분이 걸린다. dev(alpha), production순으로 동기적으로 하면 총 14분이 배포에만 걸리는 시간이다. 끔찍하지 않은가? > 전 회사에선 배포까지 20분이 넘게 걸렸었던걸로