Front-end 툴 체인 Rome 훑어보기
원문: https://aralroca.com/blog/do-all-roads-lead-to-rome
Rome이 무엇인지, 자바스크립트 생태계에 어떻게 들어맞는지와 그것에 대한 생각을 적어보려고 합니다. Rome이 현재 사용되는 모든 도구를 대체할까요? 한번 살펴봅시다.
Rome은 JavaScript 및 TypeScript 개발 시 사용하는 통합 툴 체인(CLI나 VSCode 익스텐션, 미래에는 테스트 목적으로 API를 통해 사용할 수 있는)이다. 번들링, 컴파일, 문서 생성, 포맷팅, 린팅, 압축(minification), 테스트, 타입 검사 등의 모든 작업을 하나의 CLI 아래에서 수행할 수 있는 “올인원” 솔루션을 지향하고 있습니다.
처음 듣는다면 Rome CLI로 Webpack, Babel, Prettier, Jest 등을 다룰 수 있나 궁금할 수 있습니다. 하지만 대답은 NO…다. Rome은 동일한 구성 파일을 사용해 모든 툴체인을 의존 없이 구현했습니다.
이 프로젝트는 Babel과 yarn, prepack과 React Native 프로젝트에 참여했던 Sebastian McKenzie가 진행하고 있는 프로젝트입니다.
Rome은 아직 베타버전이며 현재 완전히 구현된 영역은 linting과 formatting입니다. 다른 영역은 아직 개발중입니다.
Webpack이나 TS, Babel, ESLint같은 현재 사용하고 있는 도구들은 자체 파서를 실행해 AST(Abstract Syntax Tree, 추상 구문 트리)를 생성합니다. 그 후, AST를 조작하고 처리합니다.
이런 모든 작업에 한 가지 도구(Rome)만 사용이 되면 한 번만 파싱해 각 작업에 AST를 재사용할 수 있게 됩니다. 또한, 파일 보기나 의존 검증, 에디터와의 통합 등에 있어 과정들이 단순화됩니다.
AST 재사용
누가 좋아질까?
- 메인테이너/컨트리뷰터: 불필요한 중복을 단순화합니다.
- 개발자: 적은 자원 소비로 더 빠른 개발 경험을 얻습니다.
지금은 간단한 기능 한 가지를 사용하는데 너무 많은 도구를 구성해야 합니다. 예를 들어
import를 사용하려면 ESLint, TS, Webpack 등의 설정 또한 바꿔야 합니다.
설정의 중복
대신, 한가지 도구(Rome)를 사용하면 중복된 구성이 제거되므로, 한가지 설정 파일만 남게 됩니다.
모든 것을 수행하는 하나의 설정 파일
게다가, 일부 설정들은 서로 간 의존을 하는 경우가 있습니다. 예를 들어, Prettier는 ESLint와 포맷팅 충돌을 방지하기 위해 통합을 해야 하는 부분이 있습니다. 종종 이러한 도구들이 함께 작동하도록 하기 위해 플러그인을 추가해야 하지만, Rome은 모든 도구가 완벽하게 통합되어 있음으로 플러그인을 사용할 필요가 없습니다.
누가 좋아질까?
- 메인테이너/컨트리뷰터: Babel 같은 도구는 플러그인을 만들 수 있게 모든 내부 구조를 노출했고, 이로 인해 관리 및 발전이 훨씬 어려워졌습니다.
- 개발자: 하나의 설정파일만 구성하면 되기 때문에 플러그인 없이 개발을 단순화 할 수 있습니다. 또한, 프로젝트 간에 설정을 훨씬 쉽게 재사용 할 수 있게 됩니다.
JavaScript 생태계에서 개발 하는 우리들은 Jest나 Webpack, Prettier, Babel 같은 도구 및 플러그인에 대해
devDependencies 를 갖는 것에 매우 익숙합니다. 게다가, 그 도구들은 각각 자신의 의존성을 갖고 있습니다.Rome에서는 이러한 많은
devDependencie가 사라졌고, 게다가 Rome은 의존이 없습니다.Webpack vs Rome 의존 트리
그래서 우리는
- 더 강력한 보안: 모든 의존을 대폭 줄였기 때문에 취약점을 가질 가능성이 매우 줄어듭니다.
- 당신의 프로젝트의 더 나은 메인테이닝과 발전: 이전에는 일부 도구의 새 릴리즈를 업데이트할 경우 다른 도구와의 통합이 깨질 수 있었습니다. 이제 모든 것이 잘 통합된 하나의 큰 도구 아래 있습니다.
- Rome의 더 나은 메인테이닝과 발전: Rome에는 종속성이 없습니다. 이는 많은 유연성(flexibility)와 놀라운 혁신 잠재력을 가진 것을 의미합니다. 예를 들어, wasm을 사용해 다른 언어로 마이그레이션을 원한다면 이를 수행할 수 있게 됩니다.
- 빠른 설치:
npm install을 오래 기다릴 필요가 없습니다. 설치 항목이 적기 때문입니다.
이전 문단에서 보았듯이 Rome은 프로젝트를 시작하는 것을 훨씬 쉽게 합니다.
시작이 쉽다는 것을 알게 되면 새로운 것을 배우기 시작하는 것이 더 쉬워집니다. 지난 몇 년 동안 프레임워크 없이 JavaScript 프로젝트를 시작하는 것은 정말 복잡했습니다. 이 모든 도구를 단순화하면 많은 사람이 훨씬 더 즐겁게 JavaScript의 세계에 진입할 수 있습니다.
Photo by Annie Spratt on Unsplash
Rome의 첫 번째 단계를 수행하려면,
yarn 또는 npm 을 통해 설치한 다음 npx rome init / yarn rome init 을 실행해 기본 .config/rome.rjson 을 만들 수 있습니다.마지막으로
rome [command] 를 사용해 CLI의 모든 명령을 사용할 수 있습니다. rome check을 통해 파일의 린팅과 포맷팅을 실행하고, rome format을 통해 단일 파일을 포맷팅 하거나, rome start을 통해 디몬(deamon)을 실행합니다. rome rome --help 를 통해 가능한 명령을 확인할 수 있습니다.이 글을 시작할 때 Rome이 모든 툴 체인을 대체할 것인지에 대해 질문을 하면서 시작했습니다. 이 질문에 대한 답은 Rome의 발전과 커뮤니티에서 얼마나 채택이 될지 현재 사용되는 도구에 따라 시간이 지나면서 답변이 이루어질 질문입니다.
우선, 제 관점에서는 단기적으로는 “NO”라고 생각합니다. 기능적으로 도구들을 대체하지만 이런 도구들이 쓸모없어 지지는 않습니다. 그 도구에 의존하는 프로젝트는 여전히 많을 것입니다. 그러나 장기적으로는 “YES”라고 생각합니다. Rome이 아닐 수 있지만, Deno 같이 모든 것을 통합하는 유사한 철학을 채택한 또 다른 비슷한 접근일 수 있습니다.
내 생각에는 현재의 JavaScript 생태계는 너무 파편화 되어 있어서, 일반적으로 대부분 작업에 너무 많은 의존이 설치되는 것 같습니다. 많은 사람이 새로 시작되는 Rome이나 Deno같은 프로젝트가 생태계를 더 많이 파편화 한다고 생각하지만 나는 그 반대라고 생각합니다. 이러한 도구들은 그런 파편화를 수정하는 것을 목표로 하며 매우 긍정적이라고 생각합니다.
아마 하나의 도구가 요구에 100% 맞지 않아 기존의 도구를 사용하고 싶을 수 있습니다. 예를 들어 webpack을 컴파일러로 계속 사용하는 것을 선호할 수 있습니다. Rome의 좋은 점은 한 도구만 사용하고 싶다면 가능하다는 것입니다. 따라서, 컴파일러를 제외한 Rome의 모든 부분과 webpack을 함께 사용하는 것이 가능합니다.
자 이제 여러분 차례입니다. JavaScript / TypeScript의 도구의 미래에 대해 어떻게 생각하시나요?