A Formal Commitment to New Language Features
JSHint 블로그에 올라온 A Formal Commitment to New Language Features 글을 소개하고자 합니다.
Babel와 같은 Transpiler를 이용해 ES.next의 기능을 사용해 볼 수 있습니다만,
JSHint가 새로운 구문을 지원하기 어려운 이유에 대해 작성돼 있습니다.
그 이유 중 첫 번째로 소개한 것은 메인터넌스가 어렵다는 문제입니다.
또 하나의 대표적인 이유로는 JSHint는 커뮤니티 중심적 도구(community-driven tool) 이기 때문에,
비표준 코드를 지원하게 되면 생태계에 장기적인 영향을 미치게 됩니다. 따라서 아직 불완전한 기능 지원을 우선순위 높게 채용하지 않았음을 이야기합니다.
JSHint가 JSLint를 포크(fork)하여 만든 이유는 아래 개발자의 블로그에 작성돼 있습니다.
ES.next를 일방적으로 지원하지 않겠다는 의미가 아니라 그 기능의 제안(proposal)의 상태가 Stage 2 이상인 것만 experimental 플래그를 사용해 지원한다고 합니다. Stage 2 이상을 지원하는 것은 지나치게 빠르지도 또 느리지도 않다고 이야기하고 있습니다.
Note: TC39(Technical Committee 39, 기술 위원회#39)에서는 표준을 재정하는 단계를 아래와 같이 나누고 있습니다.
- Stage 0(Strawman) : ECMAScript에 넣고 싶은 아이디어를 논의하는 단계
- Stage 1(Proposal) : Strawman을 구체화하고 데모를 작성하거나 분석하는 단계(브라우저가 플래그로 실험적으로 지원을 하는 단계이기도 합니다)
- Stage 2(Draft) : 정식 사양을 형식에 맞게 정의하고 작성하는 단계
- Stage 3(Candidate) : Draft를 구현하고 피드백을 받는 단계
Stage 4(Finished) : ECMAScript에 정식으로 채용하고 Test262에 구현하는 단계
JSHint 3는 이 지침에 따라 아래와 같은 규칙을 정하고 있는 것 같습니다.
esnext옵션 폐지moz옵션 지속- ES6는
esversion: 6옵션으로 지원 - ES7은 제대로 표준화가 이루어지면 지원
- Stage 2 이상의 제안은
experimental옵션으로 지원
JSHint의 경쟁 상대로 ESLint나 이것을 이용한 Babel이 지원하는 Stage n의 제안도 검증할 수 있는 babel-eslint가 있습니다.
ESLint는 유연한 지원을 하기 위해 플러그인 시스템을 채용하고 있지만,
플러그인은 플러그인만의 어려움이 있어 아래와 같은 것도 논의되고 있습니다.
@mjackson FWIW (roughly) over 1/3 of ESLint users use babel-eslint. In the future ESLint won't even be required as it'll be rolled into core
— Sebastian McKenzie (@sebmck) July 10, 2015ESLint와 역할이 미묘하게 겹쳐 경쟁 상대이기도 한 JSCSの@mikesherov가 말한 것 처럼,
경쟁이 있다는 것은 건강하다는 것이기 때문에 앞으로도 검증 도구가 서로의 방침에 있어서 발전하는 것은 좋은 일이라 생각합니다.
@mikesherov @sebmck having 2 impls is fine. Better than monoculture. It's when 20 show up that sucks. Why I love Acorn AND Esprima.
— Mike Sherov (@mikesherov) July 11, 2015
