바벨 7 출시

원문 : https://babeljs.io/blog/2018/08/27/7.0.0

2년에 가까운 시간 동안 4k의 커밋, 50회 이상의 프리 릴리즈, 그리고 많은 도움에 힘입어 바벨 7 정식 출시를 발표하게 되어 흥분된다. 이번 출시는 바벨 6 이후 거의 3년 만이다! 많은 부분이 변경되었으므로, 출시 첫 주에는 우리의 사이트와 함께 하길 바란다. 바벨 7에서는 더 빨라졌고 업그레이드 도구, 자바스크립트 환경 설정, "overrides" 설정 옵션, 용량/압축을 위한 추가 옵션, JSX 프레그먼트, 타입스크립트, 새로운 제안 등 많은 것들이 만들어졌다!

바벨에게 고마움을 느낀다면, Open Collective에서 바벨을 후원하거나 Patreon에서 나를 지원해달라. 또는 당신 또는 당신의 회사가 바벨과 관련된 일을 하길 바란다. 자바스크립트 커뮤니티에서 중요한 프로젝트의 공동 소유권을 가질 수 있어 감사하다!

드디어 출시되었다! 🎉

절대 완벽할 수는 없겠지만 이제는 내보낼 준비가 되었다! @babel/core는 Next.js 6, vue-cli 3.0, React Native 0.56과 같은 도구 사용 및 워드프레스 프론트엔드 덕분에 이미 월간 510만 다운로드를 달성하였다🙂!

바벨의 역할

지난 몇 년 동안 자바스크립트 생태계에서의 바벨의 역할을 다시 소개하는 것으로써 이번 글을 시작하려고 한다.

최초의 문제는 서버 언어와 다르게, 모든 사용자가 자바스크립트에 대해서 같은 지원을 보장받을 수 없다는 것에서 시작되었다. (특히 인터넷익스플로러 구 버전에 해당) 만약 개발자들이 새로운 구문(예: class A {})을 사용하려고 한다면, 사용자들은 구형 브라우저에서 SyntaxError 때문에 빈 화면을 보게 될 것이다.

바벨은 개발자들이 최신 자바스크립트 구문을 사용하면서 변환을 통해 사용자와 하위 호환성을 유지할 수 있도록 방안을 제시했다. (class A {}를 var A = function A() {}로 변환)

자바스크립트 코드를 변환할 수 있기 때문에, 새로운 기능을 구현하는데에도 사용될 수 있다. 바벨은 TC39(자바스크립트 언어의 스펙을 정하는 조직)를 돕는 다리가 되었다.

바벨은 오늘날 자바스크립트 개발에서 필수이다. 현재 깃헙에서는 130만 개 이상의 디펜던시 리포지터리가 있으며, npm에서 월간 1700만 다운로드를 달성, 그리고 주요 프레임워크(리액트, 뷰, 엠버, 폴리머)와 회사(페이스북, 넷플릭스, 에어비앤비)를 포함해 수백 명의 사용자를 가진다. 바벨은 많은 사람이 사용법을 모르면 안되는, 자바스크립트 개발을 위한 토대가 되었다. 바벨을 직접 사용하지 않더라도 디펜던시들이 사용하고 있을 가능성이 크다.

메인테이너들은 사람이다.

바벨은 언어의 미래뿐만 아니라 커뮤니티와 생태계에 큰 영향을 미쳤다. 이러한 모든 책임을 지고 있지만, 바벨은 몇 명의 자원봉사자들이 이끄는 커뮤니티 중심의 프로젝트에 불과하다.

작년에 처음으로 팀에서 몇 명이 만날 수 있었다.

트위터

이 글을 통해서, 이 프로젝트의 상태를 모든 사람에게 상기시킬 수 있는 기회가 되길 바란다.

나는 6.0 버전 출시 몇 달 전에 합류했는데, 당시 바벨은 논쟁거리였다. 조직 대부분은 번아웃된 메인테이너들(바벨 창시자인 Sebastian을 포함해)이 이끌고 있었고, 남아있는 몇 명 조차도 바벨에 대한 애정이 없는 상태였다.

많은 메인테이너들과 마찬가지로, 우리의 역할에 대해서 어려움을 겪었다. 많은 사람들이 컴파일러의 동작 방식이나 오픈 소스 프로젝트를 유지하는 방법에 대해 공식적인 교육을 받지 못했었다. 아이러니하게도, 나는 일부러 대학에서 컴퓨터 공학을 전공하지 않았었다. 왜냐하면 컴파일러나 낮은 수준의 수업은 재미없고 어렵게 보였기 때문이다. 대신 나는 툴링, 린터, 바벨 및 자바스크립트를 언어에 더 끌렸다.

나는 오픈 소스를 사용하고 있는 사람들이 오픈 소스 프로젝트를 들여다보고, 그 오픈 소스들을 지원해 주었으면 좋겠다. (가능하다면 시간과 금전적 지원을 통해서 말이다)

많은 메인테이너들은 그들이 하는 작업에 대해 근본적으로 전문가는 아니다. 먼저 일을 시작한 것만으로도 많은 것을 성취하게 된다. 메인테이너가 되면 당신은 호기심과 겸손을 겸비하게 될 것이다. 나의 바람은 우리가 모두 "일"을 하는 것보다 프로젝트의 비전에 대한 희망이다.

바벨은 페이스북과 같은 주요 회사의 오픈 소스 팀이나 회사가 아니다. 소수의 자원봉사자만이 바벨에서 일하고 있으며, 나의 경우에는 직장을 그만두고 오픈 소스에서 풀타임으로 일을 한 지 불과 몇 달밖에 되지 않았다. 사람들은 이 "취미" 외에도 각자의 삶이 있다. 우리는 우리가 일하는 방식의 토대가 되는 것을 유지하기 위해 다함께 무언가를 하고 있는가? 아니면 그 토대가 서서히 무너지도록 내버려두는 것은 아닌가? 어떻게 오픈 소스를 유지하고 어느 선까지 받아들일 것인가? 다른 메인테이너들의 경험으로부터 배울 수 있는가?

분명히 오픈 소스가 소프트웨어를 지배했지만, 그 뒤에 있는 사람들(메인테이너들)을 고려하지 않고도 오픈 소스가 건강한 상태라고 볼 수 있을까?

#BabelSponsorsEverything

트위터

오픈 소스의 지속 가능성은 순간적으로 돈 바구니를 내미는 것과 같다. 오픈 소스를 사용하는 수천 명의 사람과 회사에 오픈 소스 프로젝트의 가치를 말하기는 쉽지만, 기꺼이 그 일에 참여하는 몇몇 사람들의 가치를 알아보는 일은 어렵다.

오픈 소스를 지원하는 방법에 여러 가지가 있을 수 있지만, 각 프로젝트 또는 사람들에게 모두 통하는 것은 아니다.

그럼 지금부터 변경 사항들을 보러 가자!

주요 변경 사항

주요 변경 사항에 대해서는 마이그레이션 가이드에 정리해 두었다. 변경 사항들은 새로운 babel-upgrade 도구를 통해 자동으로 적용될 수 있고 앞으로도 계속 추가될 예정이다.

• 관리되지 않는 노드 버전(0.10, 0.12, 4, 5)에 대한 지원을 중단한다. (참조)
• "scoped" 패키지를 사용해 @babel 네임스페이스로 변경한다. (참조) 이것은 공식 패키지를 구분하는 데 도움이 되며, babel-core는 @babel/core가 된다.
• preset-es2015와 같은 연도별 프리셋 일부를 제거하였다. (참조). @babel/preset-env는 모든 연도별 추가 기능과 특정 브라우저들을 처리하는 기능이 추가되어 있어 기존 프리셋을 대체한다.
• 또한 @babel/preset-stage-0와 같은 "Stage" 프리셋을 제거하고, 개별 제안을 명시하여 사용하도록 한다. 비슷한 이유로 기본적인 @babel/polyfill의 제안도 제거한다. (참조) 이 내용에 대한 더 자세한 설명은 전체 글을 읽어보길 바란다.
• 몇몇 패키지들의 이름이 변경된다. TC39 제안 플러그인은 -transform 대신에 -proposal로 바뀐다. (참조) 그래서 @babel/plugin-transform-class-propertie는 @babel/plugin-proposal-class-propertie가 된다.
• 사용자에게 노출된 패키지(user-facing packages)를 위한 @babel/core의 peerDependency를 추가한다. (예: babel-loader, @babel/cli 등) (참조)

babel-upgrade

babel-upgrade는 package.json와 .babelrc 환경 설정에 있는 디펜던시들을 현재 버전으로 자동 업그레이드해 줄 수 있는 새로운 도구이다.

npx babel-upgrade 커멘드로 git 리포지터리(프로젝트 폴더)에서 직접 실행하는 것이 좋다. 또는 npm i babel-upgrade -g 로 글로벌하게 설치할 수도 있다.

파일을 수정하려 한다면, --install뿐만 아니라 --write도 사용할 수 있다.

npx babel-upgrade --write --install

바벨 7의 모든 변화에 도움이 될 수 있도록 이슈를 리포팅하거나 PR을 날려주길 바란다! 앞으로의 소망은 모든 변경 사항들에 대해 이 동일한 도구를 사용하고 업데이트를 위한 PR 프로젝트 봇을 만드는 것이다.

자바스크립트 설정 파일들

babel.config.js를 소개한다. 이것은 .babelrc를 대체하거나 필수 요구 사항은 아니나, 어떤 경우 에 굉장히 도움이 될 것이다.

*.js 환경 설정 파일들은 자바스크립트 환경에서 꽤 일반적으로 사용된다. ESLint와 웹팩은 각각 .eslintrc.js, webpack.config.js 환경설정 파일들을 사용한다.

아래는 "production" 환경에서만 플러그인을 컴파일하는 예제이다. (.babelrc 파일에서 "env" 옵션을 이미 설정했을 수도 있다)

var env = process.env.NODE_ENV;
module.exports = {
  plugins: [
    env === "production" && "babel-plugin-that-is-cool"
  ].filter(Boolean)
};

babel.config.js은 .babelrc과 다른 설정 범위를 가진다. 바벨이 설정 파일을 찾을 때까지 각 파일을 찾아 올라가면서 원래 파일과 설정 파일을 비교한다. 이는 아래 소개될 overrides 옵션 사용에 좋다.

overrides로 선택적 설정하기

최근 ES2015+ 패키지 배포와 사용/컴파일링에 대한 글을 작성했었다.

새로운 바벨 설정 overrides 값 대한 섹션을 보면, overrides는 경로에 따라 다른 설정을 지정할 수 있다.

module.exports = {
  presets: [
    // defeault config...
  ],
  overrides: [{
    test: ["./node_modules"],
    presets: [
      // config for node_modules
    ],
  }, {
    test: ["./tests"],
    presets: [
      // config for tests
    ],
  }]
};

이렇게 하면 애플리케이션에서 테스트, 클라이언트 코드, 서버 코드에 대해 다른 편집 설정을 할 수 있다. 폴더마다 .babelrc 파일을 생성하지 않아도 된다.

속도 🏎

바벨은 빠르기 때문에 빌드하는데 시간이 덜 든다! v8 팀에서 요청한 패치를 받아들이고 코드를 최적화하기 위해 많이 변경되었다. 다른 훌륭한 자바스크립트 도구들과 함께 웹 도구 벤치마크의 일부가 된 것을 기쁘게 생각한다.

아웃풋 옵션

바벨은 현재 프리셋과 플러그인 옵션을 지원하고 있다. 배열에 플러그인을 감싸고 옵션 객체를 플러그인에 전달할 수 있다.

{
  "plugins": [
-   "pluginA",
+   ["pluginA", {
+     // options here
+   }],
  ]
}

일부 플러그인의 loose 옵션을 조금 변경하고 다른 플러그인들을 위한 새로운 옵션을 추가했다! 이 옵션들을 사용하려면 비규격 준수 동작(noe-spec compliant behavior)을 선택하고 무엇을 하고 있는지 알아야 한다. 이는 네이티브 구문을 사용하기 위해 컴파일을 끌 때 문제가 될 수 있다. 이러한 종류의 옵션들은 라이브러리로 사용하는 것이 가장 좋다.

• 클래스에서, 이제는 class A {}가 classCallCheck 헬퍼를 포함하지 않을 것이다.

class A {}

var A = function A() {
-  _classCallCheck(this, A);
};

• for-of 루프에서 사용되는 값이 배열인 경우에 새로운 옵션 ["transform-for-of", { "assumeArray": true }]을 사용할 수 있다.

let elm;
for (elm of array) {
  console.log(elm);
}

let elm;

for (let _i = 0, _array = array; _i < _array.length; _i++) {
  elm = _array[_i];
  console.log(elm);
}

• preset-env을 위해 loose 모드에서 transform-typeof-symbol 플러그인을 제외했다. #6831

우리는 이미 이러한 일을 처리하는 많은 라이브러리를 찾았으므로, 기본적으로 이 작업을 처리하도록 했다.

기본 동작은 바벨을 끄거나 preset-env를 사용하기 위해 가능한 한 규격을 준수하는 것이나 적은 용량의 아웃풋을 필요로 할 수도 있다(각 프로젝트마다 절충안을 만들 수 있다). 우리는 이 일을 쉽게 할 수 있도록 더 나은 문서와 도구를 만들려고 한다.

"Pure" 주석 지원

#6209 이후에, 트랜스파일 된 ES6 클래스들은 /*#__PURE__*/ 주석이 달리게 되었다. 이 주석은 사용되지 않는 코드를 제거하기 위해 Uglify와 babel-minify와 같은 미니파이어에게 힌트를 제공한다. 이 주석은 다른 헬퍼 함수에도 추가되었다.

class C {
  m() {}
}

var C =
/*#__PURE__*/
function () {
  // ...
}();

미니파이어 힌트와 최적화에 대한 더 좋은 방법들이 있다면 알려주길 바란다!

구문(Syntax)

TC39 제안 지원

스테이지 프리셋을 제거하고, 스테이지 4 미만의 제안에 대해서는 사용자가 직접 명시하도록 변경한 정책에 대해 다시 한 번 언급하고 싶다.

한 가지 우려되는 점은, 사람들이 이들 문법이 앞으로 변경되지 않을 거라는 착각을 하도록 만드는 것은 아닐까 하는 점이다. 하지만, 이는 사실이 아니며, 특히 스테이지 0 또는 1의 경우 앞으로 변경될 가능성이 더욱 높다. 이 글에서 새로운 아이디어에 대한 자세한 이야기를 다루고 있다.

여기 바벨이 지원하는 새로운 구문에 대한 목록이 있으며(이 기능들은 추가, 삭제, 중지될 수 있다는 점을 유의하기 바란다), 이들은 모두 7 버전에 추가되었다.

• ES2018: Object Rest Spread (var a = { b, ...c })
• ES2018 (new): Unicode Property Regex
• ES2018 (new): JSON Superset
• ES2015 (new): new.target
• Stage 3 (new): Class Private Instance Fields (class A { #b = 2 })
• Stage 3 (WIP): Static Class Fields, Private Static Methods (class A { static #a() {} })
• Stage 3 (new): Optional Catch Binding try { throw 0 } catch { do() }
• Stage 3 (new): BigInt (syntax only)
• Stage 3: Dynamic Import (import("a"))
• Stage 2 (new): import.meta (syntax only) (import.meta.url)
• Stage 2 (new): Numeric Seperators (1_000)
• Stage 2 (new): function.sent
• Stage 2: export-namespace-from (export * as ns from 'mod'), export-extensions에서 분리되었다.
• Stage 2: 데코레이터(Decorators). 진행 상황에 대한 최신 정보를 확인하라!
• Stage 1: export-default-from (export v from 'mod'), split from export-extensions
• Stage 1 (new): Optional Chaining (a?.b)
• Stage 1 (new): Logical Assignment Operators (a &&= b; a ||= b)
• Stage 1 (new): Nullish Coalescing Operator (a ?? b)
• Stage 1 (new): Pipeline Operator (a |> b)
• Stage 1 (new): Throw Expressions (() => throw new Error("a"))

모든 제안들의 변경 사항을 매번 확인하는 것은 누구에게나 어려운 일이므로, 우리가 정리하고 있는 babel/proposals를 확인하길 바란다.

타입스크립트 지원 (@babel/preset-typescript)

우리는 타입스크립트 팀과 협력해 바벨이 @babel/preset-typescript를 사용하여 타입 구문을 파싱하고 변환할 수 있도록 했다. @babel/preset-flow로 플로우를 처리하는 것과 비슷하다.

더 자세한 내용은 타입스크립트 팀이 작성한 글을 확인하라!

이전(타입이 사용됨):

interface Person {
  firstName: string;
  lastName: string;
}

function greeter(person : Person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

이후(타입이 제거됨):

function greeter(person) {
  return "Hello, " + person.firstName + " " + person.lastName;
}

플로우와 타입스크립트는 자바스크립트 사용자가 점진적인 타이핑을 할 수 있게 도와주는 도구이며, 바벨에서 이 두 가지를 모두 사용하고자 한다. 우리는 호환성을 유지하고 새로운 기능을 지원하기 위해 페이스북과 마이크로소프트 팀과 가깝게 일할 계획이다.

이 통합은 새롭기 때문에 몇몇 구문은 완벽하게 지원되지 않을 수 있다. 이슈를 리포팅하거나 PR을 날려주면 감사하겠다.

JSX 프래그먼트 지원 (<>)

리액트 블로그에서 언급했듯이, JSX 프레그먼트는 beta.31부터 지원되었다.

render() {
  return (
    <>
      <ChildA />
      <ChildB />
    </>
  );
}

// output 👇

render() {
  return React.createElement(
    React.Fragment,
    null,
    React.createElement(ChildA, null),
    React.createElement(ChildB, null)
  );
}

바벨 헬퍼 변경

babel-upgrade PR은 진행중이다.

@babel/runtime은 @babel/runtime과 @babel/runtime-corejs2로 분리되었다. (PR) @babel/runtime은 바벨 헬퍼 함수만 포함하고 있으며, @babel/runtime-corejs2은 바벨 헬퍼 함수 뿐만 아니라 Symbol, Promise와 같은 다른 폴리필 함수들도 포함한다.

바벨은 재사용 될 수 있는 코드에 어떤 함수를 주입해야 할 수도 있다. 이것을 모듈 간에 공유되는 함수처럼 "헬퍼 함수"라고 부른다.

이것에 대한 예제로 class 컴파일하는 것을 들 수 있다. (loose 모드를 사용하지 않는 경우)

명세에 따르면 클래스를 호출할 때에는 new Person()과 같이 사용해야 하지만, 클래스가 함수로 컴파일되고 난 후에는 기술적으로 Person()이라고 호출하는 것이 가능하기 때문에, 런타임에 이를 위한 체크를 추가해주고 있다.

class Person {}

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

var Person = function Person() {
  _classCallCheck(this, Person);
};

디펜던시로써 @babel/plugin-transform-runtime과 @babel/runtime을 사용하면, 바벨로 개별 함수를 추출할 수 있고 다음처럼 모듈을 포함시킬 수 있다.

var _classCallCheck = require("@babel/runtime/helpers/classCallCheck");

var Person = function Person() {
  _classCallCheck(this, Person);
};

같은 동작을 하는 것으로 external-helpers와 rollup-plugin-babel이 있다. 우리는 앞으로 이 작업을 자동으로 해줄 수 있는지를 조사하고 있다. 조만간 바벨 헬퍼에 대한 글을 찾아보아라.

자동 폴리필화 (실험적인)

폴리필은 Promise, Symbol과 같은 기능들이 지원되지 않는 환경에서 사용할 수 있도록 도와준다. 컴파일러로써 바벨(구문 변형)과 폴리필이 하는 일(내장된 함수/객체 구현)을 구분하는 것은 중요하다.

@babel/polyfill을 사용하면 포함하는 모든 것을 가져오기에 쉽다.

import "@babel/polyfill";

이것은 전체 폴리필을 포함하지만, 브라우저에서 이미 기능을 지원하는 경우 모두 import 할 필요가 없다. 이는 @babel/preset-env로 구문을 해결하려고 하는 것과 같은 문제이다. useBuiltins: "entry" 옵션을 사용하면 전체에서 필요로 하는 것만 분할해서 import 하게 된다.

그러나 코드상에서 사용되는 폴리필만 import 하는 것이 가장 좋다. "useBuiltIns: "usage"는 이것을 가능하게 하는 첫 시도이다. (문서)

이 옵션은 각 파일을 통해 실행되며, 코드에서 "사용되는" 것만 각 파일의 최상단에서 import로 주입된다. 다음은 예이다.

import "core-js/modules/es6.promise";
var a = new Promise();

아래 추론은 완벽하지 않으며 거짓이 있을 수 있음에 유의하라.

import "core-js/modules/es7.array.includes";
a.includes // assume a is an []

이 분야의 또 다른 아이디어로는, 서비스에 의존하는 것이 괜찮다면 polyfill.io를 사용하는 것이다. (또는 Kent C. Dodds가 사용한 페이팔에서 호스팅 된 서비스를 빌드하는 방법에 대한 글을 읽어보라)

기타

바벨 매크로 🎣

바벨의 좋은 점은 연결 가능한 도구라는 것이다. 수년에 걸쳐, 바벨은 코드 변환 플랫폼 에서 "6to5" 컴파일러(역자주: ES6 코드를 바닐라 ES5 코드로 변경)가 되었다. 사용자와 개발자 경험을 위해 몇 가지 멋진 최적화를 한다. 특정 라이브러리와 API 성능 및 호환성을 개선하기 위한 사용 사례로부터 수많은 바벨 플러그인이 개발되었다. (일부 "라이브러리들"은 완벽하게 변환되어 런타임이 전혀 없다)

불행하게도, 코드상에 이러한 플러그인들을 추가하는 것은 설정 변경을 필요로 한다(create-react-app과 같은 어떤 툴킷들은 필요하지 않다). 그리고 바벨이 실행되면서 일어난 일들에 대해서 개발자가 알아야하기 때문에 코드는 더 복잡해진다. 이러한 문제점들은 Kent C. Dodds의 babel-plugin-macros로 해결될 수 있다.

일단 babel-plugin-macros를 설치하고 설정 파일에 추가(이것은 create-react-app 버전 2를 포함한다)하면, 매크로를 사용하기 위해 설정을 고민할 필요가 없다. 추가로 앱이나 코드 특정 부분을 위해 사용자 정의 변환을 작성하기에도 쉽다.

"babel-plugin-macros와 함께 환경 설정 없는 코드 변환"에 대한 원문에서 babel-plugin-macros에 대해 더 배울 수 있다.

모듈 타겟팅

바벨은 자바스크립트 작성자에게 제공되는 변환과 호환성 영향을 균형있게 맞추려고 노력해 왔다. 바벨 7에서는 모듈/모듈 패턴의 인기가 높아짐에 따라 바벨 설정이 훨씬 쉬워졌다.

특히 바벨로 트랜스파일 된 애플리케이션에 대해 인기있는 웹 프레임워크(1, 2) CLI 도구들을 통해 자바스크립트 코드가 약 20% 정도 감소되는 효과를 보였다.

메타 데이터 실행자와 더 나은 기본 설정

@babel/core에 caller 옵션을 추가해 프리셋/플러그인에 메타 데이터를 전달할 수 있다. 예를 들어, babel-loader는 이와 같은 것을 추가하여 preset-env가 자동으로 모듈 변환을 못하게 할 수 있다. (rollup과 동일)

babel.transform("code;", {
  filename,
  presets: ["@babel/preset-env"],
  caller: {
    name: "babel-loader",
    supportsStaticESM: true,
  },
});

이 옵션은 기본 설정을 좋게 만들어 추가 설정을 덜 할 수 있는 방법을 제공하기 흥미롭다. 때문에 웹팩/롤업의 경우, 바벨 대신에 자체 모듈 변환을 사용하도록 자동으로 지연시킬 수 있다. (import("a")와 동일) 미래에 이 기능을 활용할 수 있는 툴링을 더 많이 찾아보라.

class C extends HTMLElement {}

가장 오래된 이슈는 제목에 있다. (참조)

바벨은 네이티브 내장 객체(Array, Error 등)에 대한 확장을 지원할 수 없다는 경고를 항상 포함하고 있었으나, 이제는 지원할 수 있다! 우리는 이것에 대해 많은 문제들을 겪었다. 🎉 Andrea처럼 축하한다!

이 변경 사항은 클래스 플러그인에 적용되었으므로, preset-env을 사용한다면 자동으로 활성회되어야 한다.

웹사이트 변경 🌏

우리의 사이트를 Jekyll에서 Docusaurus로 변경했다.

우리는 Crowdin으로 번역을 진행하고 있으며, 바벨 7은 이것을 하기에 좋다.

REPL

리액트 컴포넌트로 REPL을 다시 작성했으며, Ives와 협력해 CodeSandbox를 잘 통합했다. 이것은 REPL로 npm에서 어떤 플러그인 또는 프리셋을 설치할 수 있도록 도와준다. 그뿐만 아니라 CodeSandbox에서 가져오는 모든 업데이트도 가져올 수 있다.

우리는 Rails Girls Summer of Code에 다시 참여하고 있다! Gyujin과 Sujin은 Boopathi의 babel-time-travel을 REPL에 통합하기 위해 열심히 노력하고 있다.

바벨, ASTs 및 다른 도구들이 잘 동작하도록 만들 수 있는 기회가 여기 있다.

노래를 부른다 🎶

할렐루야 - 바벨의 찬송가

어느 날 Angus는 놀라운 노래를 우리에게 선사했는데, 어찌 "공식적인" 노래를 만들지 않을수가 있겠는가? Shawn은 여기에 멋진 커버곡을 만들었다.

리포지터리의 SONG.md에서 찾을 수 있다. 우리는 다른 프로젝트들이 이것을 따라해보길 바란다!

다음은?

• 바벨은 본질적으로 자바스크립트를 컴파일하는 것과 연결되어 있다. 제안/작업할 새로운 추가 사항들이 있을 때 수행해야 할 일들이 있다. 이 작업에는 "안정화" 되기 전 구문을 구현하고 유지하기 위한 시간/노력이 포함된다. 우리는 업그레이드 과정, 새로운 기능 교육, 표준/언어 디자인 교육, 사용 편의성 및 다른 프로젝트와의 통합 등 모든 과정에 신경 쓴다.

  • 관련 : Nicolò 덕분에 바벨에 새로운 데코레이터 제안을 거의 완성했다. 새 제안은 이전의 것과 완전히 다르며 훨씬 강력하기 때문에 긴 여정이 되었지만(1년 이상 걸렸다!) 거의 다 왔다 🎉. 다음 마이너 버전 중 하나에서 변경 사항을 설명하는 블로그 게시물과 함께 이 제안이 포함되어 출시될 것이다.
• Boopathi는 공을 들여 babel-minify를 관리해왔다. 따라서 우리는 그다음에 1.0 버전을 준비할 것이다!
• 플러그인 정렬, 더 나은 유효성/에러 검사, 속도, loose/스펙 옵션 재설계, 캐싱, 비동기적으로 바벨 사용, CI로부터 자체 구축, 스모크 테스트(smoke test), test262 실행 등 새로운 기능이 많이 있다. 다른 아이디어에 대해서는 이 로드맵 문서를 확인하라!

우리에게는 숨겨진 계획이 없다. 우리는 이 커뮤니티에 봉사하는 것으로 최선을 다하고 있다.

오픈 소스는 거울이다.

우리에게 모든 아이디어를 달성할 수 있는 시간과 자원이 있다면 정말 좋을 것이다. 그러나 이번 출시에서 보여주었듯이 예상보다 굉장히 오래 걸린다!

이번 출시는 왜 이렇게 오래 걸린 걸까? 추가하거나 고칠 수 있는 것들 중에서 우선순위를 잘 정하지 못했기 때문인가? 끝까지 근본적인 문제와 눈앞의 문제를 비교하면서 고쳐서인가? 깃헙, 슬랙, 트위터에서 다른 사람들을 도와주느라 산만해져서인가? 시간을 예측하고 이러한 문제들의 어려움을 이해하면서 자원봉사자로서 과다한 커밋을 하는 것은 나쁜가?

우리는 자신에 대한 기대치를 너무 높게 책정한 걸까? 또는 다른 사람들이 자신의 필요에 따라 압력을 가하고 있는가? 나는 버그가 해결되지 않은 이유와 동시에 왜 출시되지 않는지를 묻는 메세지를 보면 무섭다. 그것들을 급히 끝내고 싶지만 이것은 진지하게 받아들여야 한다.

나는 지난 주 React Rally에서 이러한 생각들과 고생들을 토로하고자 했다. (오픈 소스) 유리잔을 보는 것을 통해, 당신이 이런 내용들을 들을 수 있는 기회가 되길 바란다. 내 자신에게 묻는 질문으로는 유지 보수 작업 시간이 늘어나고, 불안해하고, 비현실적인 기대에 대한 피할 수없는 사이클에 대해 어떻게 해야 하는가이다.

삶의 많은 부분과 마찬가지로, 우리가 하는 일은 성격을 반영하고 우리가 실제로 어떤 모습인지를 보여준다. 우리가 하는 행동은 그 자체로 더 좋든 나쁘든간에 우리를 변화시킬 수 있다. 우리의 일을 진지하게 받아들인다면, 우리 문화에 아주 깊숙이 박혀있는 습관들에 대해 책임감을 가져야한다. 이 습관들은 즉각적인 희열, 지표상의 성공, 권리 부여 vs 감사, 과업에 대한 자부심이다.

이 모든 것에도 불구하고, 이번 출시는 가치있었다.

감사 인사

바벨 7 출시는 정말로 흥미로운 일이다. 우리가 성취하고 실현한 것들을 되돌아볼 뿐만 아니라 작년에 얼마나 많은 시간과 노력을 투입했는지를 알 수 있다. 이 과정에서 일어난 기회와 경험들은 믿기 어려울 정도다. 전 세계의 기업들과 상호 작용하면서 도와주었고, 방문한 모든 도시에서 친구들을 만났다. 그리고 이 믿을 수 없는 여정에 대해 솔직하게 이야기하면서 우리는 함께 해왔다.

개인적으로 나는 많은 정신적인 에너지를 쏟아붓지 않을 수 있었고, 여정과 함께 한 많은 사람들에게 감사하다. 특히 Logan Smyth와 Brian Ng에게 정말 감사하다. Logan Smyth는 핵심 동작 방식을 변경하기 위해 많은 시간을 보냈고 프리랜서로 일하는 동안에도 메신저로 우리에게 많은 도움을 주었다. Brian Ng는 바벨을 관리하고 블로그 게시물과 이야기들을 모두 검토해주었다. Daniel Tschinder, Sven Sauleau, Nicolò Ribaudo, 그리고 Justin Ridgewell 모두가 이번 출시를 가능하게 하고 즐겁게 작업할 수 있게 도와주었다.

슬랙, 트위터 및 깃헙의 모든 프로젝트의 커뮤니티 회원들에게 우리가 사용자를 위해 무엇을 하는지 이해할 수 있도록 외쳐본다. Behance/Adobe의 친구들에게 감사의 말을 전한다. 그들은 내가 바벨에서 풀 타임으로 일하기 전 하프 타임으로 일할 때 거의 1년 동안 후원해주었다(또한 Babel 7을 생산 전반에 걸쳐 테스트 할 수 있게 도와주었다). Open Collective의 스폰서들, 특히 Trivago와 Handshake에게도 감사하다. 그리고 친구와 가족 그들의 사랑과 지원에 감사드린다.

이 시점에서 우리는 많이 지쳤으나, 이렇게 봉사하는 것은 진정으로 영광이며 특권이었다고 생각한다. 그래서 우리는 당신이 이번 출시에 대해 감사하길 바란다!