2012년 node.js는 잘 진행되었습니다. 우리는 일정한 핵심 기여와 활발한 커뮤니티를 가지고 있었고, 세계에서 가장 빠르게 자라고 있었다고 확신했습니다. 최근 몇몇 사람들은 프로젝트의 소유권에 대한 그들의 걱정을 알렸습니다. 커뮤니티는 프로젝트를 성공으로 이끌어 왔고 나와 여러 사람의 걱정은 커졌습니다.
2014년. 거의 모든 사람이 핵심(core)을 종료하는 것에 동의했고 여기에 큰 문제가 있었습니다. 우리는 모두 어떻게 이 문제를 해결할지에 대한 아이디어가 있었지만, 시도할 수 없었습니다. 왜냐하면, 우리의 소유가 아니었기 때문입니다. 몇 달 후 io.js는 문제 해결의 아이디어를 시도해보기 위해서 만들어졌고 더 많은 기여자를 참여시키고 프로젝트를 배포했습니다.
이런 아이디어는 잘 먹혔습니다. 열린 참여, 자유로운 기여 정책 그리고 정기적 배포는 더 많은 기여자를 모으고 프로젝트를 개선하기 위한 것이었습니다.
우리는 그 커뮤니티의 모든 레벨에 기여한 프로젝트도 만들었습니다. 실행 그룹은 웹 사이트를 유지하고 전파하는 그리고 흐름을 구현하는 그룹입니다.
우리는 현실적으로 개인이나 회사가 소유한 io.js의 다양한 자산들을 커뮤니티 소유의 법인 없이 커뮤니티 소유가 되는 것을 고려하고 있습니다. 도메인 이름은 Fedor의 소유이고, GitHub org를 위한 결제 계약은 Colin, 배포를 결정하는 키를 가진 것은 NodeSource인 등의 이유 때문입니다. 이 문제들이 2012년의 node.js의 문제가 아니었던 것처럼 현재의 모든 소유자가 선의로 행동하는 이 소유권들은 급한 문제가 아닙니다. 더 좋은 결과를 얻고 싶지만, 이 문제는 더 나빠졌고, 나의 밤잠을 설치게 했습니다.
커뮤니티와 많은 회사가 io.js 프로젝트를 지원했습니다. 빌드 자원은 DigitalOcean, Rackspace, NodeSource, Linaro, Scaleway, Joyent와 Voxer가 기부하고 있습니다. 일찍이 TC의 개발자들이 NodeSource, Strongloop, Voxer와 Walmart에서 io.js만을 위해 일하기 위해 고용되었습니다. 프로젝트는 커뮤니티에 의해 운영되지만 우리는 계속 회사의 도움으로 프로젝트를 진행해 나갔습니다.
우리는 프로젝트 운영이라는 좋은 일을 마쳤지만, 우리가 하지 못한 많은 것들이 있습니다. 우리는 직접적인 재정자원을 가지지 못했기 때문입니다. 전통적 마케팅, 공개적/분석적 관계, 그리고 법적으로 모두 그대로입니다. 프로젝트 초기에 이런 문제들은 거의 없었지만 우리는 이 문제들을 우리의 계속된 성공의 장벽으로 키웠습니다. 우리는 이 끝나지 않은 프로젝트에서 이익을 추구하지 않습니다. 사실 우리가 너무 오랫동안 이 문제에 대해 기다린다면 프로젝트를 둘러싼 상업적 관심들은 프로젝트의 주인이 되려고 하거나 무산될 수 있습니다.
io.js는 집이 필요합니다. 그 집은 여전히 커뮤니티에 의해 운영되는 프로젝트를 지원할 수 있는 중립적 기관입니다.
작년 7월 나는 모든 종류의 structures 그리고 지지와 함께 다양한 재단을 찾기 위한 시간을 보냈습니다. 내가 얻은 것은 다른 핵심 기여자들과 Linux Foundation의 Collaborative Projects Initiative를 통해 프로젝트를 준비하라는 조언이었습니다.
핵심은 자치권입니다. 커뮤니티는 프로젝트를 운영하고 기술적인 결정을 내리고, 배포하는 등의 일을 합니다. io.js의 모든 것은 앞으로도 커뮤니티에 의해 관리 될 것입니다.
우리는 자치권이 얼마나 강력하고 중요한지 이미 알고 있습니다. 이 자치권은 io.js 실행 그룹 모델의 근간입니다.
재단을 유지하려면 돈이 필요하고, 돈은 재단에 영향을 줄 수 있습니다. 이 외에는 별다른 방법이 없습니다. 궁금한 점은, 그 영향력의 범위가 어느 정도일까 하는 것입니다. 만약 우리가 이 영향력을 무시하거나 이 영향력 주변에 구조물을 건설하지 않는다면, 더 넓은 영역에서의 비공식적인 영향을 받을 수 있습니다. 대신에, 재단에 협력하겠다는 표현을 한 재단 이사회의 이사를 기부자로 갖는 방법이 더 좋을 수 있습니다.
이사회는 재단의 이사회를 관리합니다. 또한, 내규와 마케팅을 담당할 직접적인 역할을 하고 있습니다. 이 말은 재단이 관심 있는 단일 사업을 독점하겠다는 말도 아니고, 어떠한 법적 장벽도 이해하고 해결할 수 있도록 해야 한다는 말입니다.
배포를 포함한 모든 기술적 결정은 이사회로부터 나온 자치권을 가진 기여자들에 의해서 관리됩니다. 이사회에서 기술을 담당하고 있는 구성원들은 프로젝트의 요구를 이사회로 전달하기도 합니다.
2월 초, Joyent는 node.js 자산을 재단에 포함하겠다고 알렸습니다. 그 재단은 지금 Linux Foundation의 지원을 받고 위에 설명한 대로의 구조를 가지고 있는 형태입니다.
얼마 전, node.js, io.js와 어울리던 Linux Foundation이 관리 모델과 새로운 재단으로 프로젝트들을 다시 가져오는 기여 정책위에서 움직이기 시작했습니다. 관리, 실행집단들, 개발통합정책들은 준비되어있습니다.
이 재단의 정책들은 우리가 만든 io.js를 진행할 수 있게 보호하도록 설계되었습니다. 그들은 자유 기여 정책을 채택했고, 글자 그대로의 io.js의 열린 지배 구조를 채택했습니다. 그뿐만 아니라 이 재단은 위 정책 아래서 관리 자산을 소유할 수 있는 중립적인 기관과 함께 지원합니다.
그래서 우리는 조직되어 있고 우리가 참여하길 바라는 재단이 필요합니다. 개인적인 생각으로 io.js를 위한 이상적인 구조로 되어 있으면 좋겠습니다. 추가로 여전히 양분된 node.js와 io.js 커뮤니티의 분열과 혼란이 종식되기를 바랍니다. 만약 선택할 수 있다면, 우리는 이 모든 것을 얻고 싶고 관리 방법, 배포 과정, 그리고 실행 그룹을 온전히 지켜내고 싶습니다.
Node.js 일본 유저 그룹 대표인 후루카와(@yosuke_furukawa)입니다. 루비마에는 처음
글을 써보네요. 잘 부탁드립니다.
오늘은 JavaScript의 기본적인 이야기와, 앞으로의 JavaScript인 ECMAScript2015(구
ECMAScript6)의 이야기를 중심으로 할까 합니다.
ECMAScript2015(이하 ES2015)는 올해 6월에 다음 공식 ECMAScript 사양으로
발표되었습니다. 이 ECMAScript의 사양을 준수한 언어 구현이 JavaScript이며, 간단히
설명하면 앞으로의 브라우저에는 이 ES2015의 사양을 준수하는 새로운 JavaScript를
사용할 수 있게 됩니다.
하지만 이것은 이후의 브라우저이며, 현재 배포 중인 브라우저에서는 사용할 수
없습니다. ES2015의 기능을 지원하는 브라우저를 기다리지 않고, ES2015로 구현해,
이것을 지금 배포 중인 브라우저에서도 동작하게 하는 트랜스파일러 babel(구 6to5)에
대해서 이번에 설명할까 합니다.
또, Ruby를 쓰시는 분들 중에 웹 애플리케이션을 만드시는 분들도 많다고
생각합니다만, 이 babel은 다음 Sprockets의 v4.x에 도입을 검토하고 있고, 새로운
Sprockets에서는 ES6로 작성 가능해질 수도 있습니다.
트랜스파일러의 장점
트랜스파일러란, ES2015 이후의 문법으로 적힌 JavaScript를 지금 사용 중인
브라우저에서도 사용할 수 있게 변환하는 도구입니다.
ES2015는 6월에 사양 공개가 예정되어 있으며, 활발하게 토론 중입니다. Chrome의 개발
빌드(Canary)나 Firefox의 개발판(Aurora)에도 많은 ES2015의 기능이 구현되어
있으며, 일부 기능은 이미 지금 브라우저에서도 사용할 수 있게 되었습니다. 하지만
모든 기능을 사용할 수 있는 브라우저는 아직 없습니다.
더욱이, JavaScript에는 다른 언어에서는 반드시 있을 법한 일반적인 기능이 없을
때가 많고, 그것을 보완하기 위한 Underscore라는 라이브러리나 CoffeeScript,
TypeScript, JSX 같은 altJS가 나오게 되었습니다.
ES2015에 대응하는 JavaScript를 사용함으로써, 라이브러리가 필요 없게 되어, 기존
라이브러리를 줄일 수 있게 된다든가, altJS에 기대지 않고도 풍부한 언어 기능을
사용할 가능성이 커졌습니다.
또 수 년 후에는 ES2015가 널리 퍼져있을 거라 생각하면, 그때가 되기 전에 ES2015의
새로운 문법, 신기능을 배워두는 편이 부드럽게 이전할 수 있습니다.
ECMAScript 2015에 대하여
ECMAScript 2015에는, 밑에 있는 사양이 기능으로 추가됩니다.
let/const에 의한 블록 스코프
Map/Set/WeakMap/WeakSet에 의한 컬렉션
형을 정의하는 클래스
제너레이터/for…of
Promises
Template String Literals
화살표 함수
모듈
babel에 관하여
지금 가장 업데이트가 자주되는 트랜스파일러 중 하나입니다. 다른 트랜스파일러도
몇 가지 있지만, 새로운 문법을 가장 많이 지원하고 있는 게 babel입니다. 덤으로 읽는
법은 정해저 있지 않습니다. 여러 읽는 법이 허용되므로, "바벨"이 아니라 "바브"로
읽어도 된다고 합니다.[1]
ES2015에는 여기에 전부 다 소개하기 힘들 정도로 많은 기능이 들어있습니다.
개인적으로 중요하다고 생각하는 것은 소개하겠지만, 전부 확인하고 싶으신 경우엔 ES2015의 드래프트를
일독하시길 권합니다.
ES2015의 목표는 아까 말한 드래프트에 적혀 있고, 다음과 같은 내용입니다.
ECMAScript 제6판의 목표에는 다음과 같은 내용이 포함되어 있습니다.
대규모 앱의 개발 지원
라이브러리 구축지원
다른 언어에서 컴파일 대상으로 사용될 것
구체적인 개선안으로,
모듈화
클래스 정의
블록 스코프
iterator, generator
비동기 프로그램을 위한 Promise
디스트럭처링
꼬리 재귀 최적화
라는 내용이 포함되어 있습니다.
또, ECMAScript의 라이브러리로 map, set, binary 배열, 유니코드 보조 문자, 정규표현
확장이 빌트인으로 추가 됩니다. 이런 빌트인 기능을 서브 클래스로 확장하는 것도
가능합니다. 즉, 대규모 개발을 견딜 수 있도록, 적절히 모듈화하고, 적절한 단위로
클래스를 설계해 블록 스코프로 변수를 한정적으로 취급하는 것도 가능합니다.
또 비동기 프로그래밍에 관해서는 Promise로 비동기 처리를 추상화할 수 있게
되었습니다. 더욱이 iterator나 generator를 사용해 지연 반복 처리도 할 수 있게
되었습니다. 이런 기능은 관계형 언어의 흐름에 따르는 거라 필자는 생각하고 있고, 또
꼬리 재귀의 최적화도 이런 유행을 따르는 기능 추가라고 생각합니다.
그러면, 이런 기능에 대해 하나하나 소개해보도록 하겠습니다. 사실 그 밖에도
Template String Literals라던가, 화살표 함수가 정의되어 있지만, 이 글에서는
설명하지 않겠습니다.
모듈화
모듈을 나눌 수 있게 되었습니다. 여태까지 JavaScript에서는 언어 레벨의 모듈
분할이 불가능 했습니다. 그래서 JavaScript를 모듈화해 프론트에서 읽을 때에는
require.js를 사용하거나, browserify를 사용하거나 해서, 라이브러리로 해결하거나,
전역 공간에 커스텀 이름 공간을 만들어 거기에서 만드는 등의 처리를 했습니다.
ES2015부터는 이런 모듈화를 하기 위한 전용 구문 export와 import를 사용할 수
있게 되었습니다.
기본적으로는 commonjs와 비슷합니다. 즉, export로 객체를 import할 수 있게 하고,
require 대신 import 구문으로 객체를 사용할 수 있게 합니다.
그 밖에…
그 밖에 =>로 함수를 정의하는 Arrow Functions나 문자열 중간에 변수를 넣거나
히어독을 사용할 수 있는 Template String Literals, Symbols이나 Proxy등 전부 다
언급하기 힘들 정도로 많은 기능이 있습니다.
이후의 ECMAScript2015의 전망
위의 언급에서도 알 수 있듯이, JavaScript에 클래스나 모듈이 도입되어, 최적의
단위로 모듈과 클래스를 분해해 설계하는 것이 가능해졌습니다. 또 let이나 const로
변수의 스코프를 제한할 수도 있게 되었습니다. 이런 기능은 대규모 앱 개발을 할
때나 라이브러리를 만들 때 도움이 될 것입니다.
또, generator/iterator/Promise 등의 함수형 프로그래밍 개념이 도입되고, 꼬리
재귀의 최적화로 부작용을 줄이는 작성법도 할 수 있게 되었습니다. ES6에는
ES5까지의 방법보다 현대적인 기능이 들어 있습니다.
이미 ECMAScript의 사양을 정한 TC39는 다음 ES7에 대한 준비도 하고 있습니다.
현시점에서는 아직 검토 중입니다만, async-await라는 비동기 호출을 동기처럼 호출할
수 있는 C#에 있는 기능이라든가, Optional Typing 기능으로 인한 types나 Object의
감시를 하는 Object.observe라는 기능이 검토되고 있습니다.
이런 기능 전부 브라우저에서 사용 가능하게 되는 건 아직 훗날의 일입니다만,
babel에는 몇 가지 실험적으로 먼저 구현해본 ES7의
기능도 있습니다.
또 babel에는 구현되어 있지 않더라도, flow와 함께 사용해 타입 검사를 하거나,
jsx와 함께 사용해 전에 있었던 E4X 같은 XML 리터럴을 사용할 수도 있게
되었습니다.[2]
babel을 사용해 새로운 JavaScript를 배우고 싶으신 분들을 위해 tower-of-babel이라는 ES6
튜토리얼 학습 도구를 만들었습니다.
한국어로 번역되어 있으니 이것도 한번 해보세요.
정리
앞으로의 JavaScript인 ES6의 이야기를 트랜스파일러인 babel과 함께 설명했습니다.
ES6의 사양은 확정되지 않았고, 지금 사양에 관한 피드백을 받는 중입니다. 이
단계에서 적극적으로 ES6를 사용해 커뮤니티를 활발하게 하고 싶습니다. 버그나
문제가 있으면 피드백하면 개선될 가능성도 있습니다.
net: socket.connect()은 이제 사용자 정의 DNS 해결 메커니즘을 위한 'lookup' 옵션을 받을 수 있습니다. 기본값은 dns.lookup()입니다.(Evan Lucas) #1505
npm: npm을 2.9.0으로 업그레이드 했습니다. 더 자세한 내용은 릴리스 노트 v2.8.4과 v2.9.0을 참조하세요. 주목할 만한 것들은 다음과 같습니다.
npm init -y를 사용자 입력 없이 할 수 있도록 기본 저자 필드에 대한 지원을 추가했습니다.(@othiym23) npm/npm/d8eee6cf9d
npm outdated와 npm update에 지역 모듈이 추가되었습니다.(@ArnaudRinquin) npm/npm#7426
npm version의 버전 번호 앞에 붙는 접두사는 이제 tag-version-prefix로 설정할 수 있습니다.(@kkragenbrink) npm/npm#8014
os: os.tmpdir()은 이제 크로스 플랫폼에서 일관되게 동작하고 더 이상 어떤 플랫폼에서도 경로 뒤에 슬래시를 붙여 반환하지 않습니다.(Christian Tellnes) #747
process:
process.nextTick()의 성능이 벤치마크 스위트에 의하면 2-42% 향상되었습니다. 이는 코어에서 많이 사용되기 때문에 주목할 만합니다.(Brian White) #1571
새 process.geteuid(), process.seteuid(id), process.getegid(), process.setegid(id) 함수로 프로세스의 UID와 GID를 효율적으로 get, set할 수 있습니다.(Evan Lucas) #1536
repl:
NODE_REPL_HISTORY_FILE 환경 변수에 사용자가 접근할 수 있는 파일로 설정하면 REPL 이력을 세션 간에 유지하게 할 수 있습니다. NODE_REPL_HISTORY_SIZE로 최대 이력 크기를 결정할 수 있으며, 기본값은 1000입니다.(Chris Dickinson) #1513
NODE_REPL_MODE 환경 변수를 사용해 REPL을 sloppy, strict, magic(기본값) 3가지 모드 중 하나로 할 수 있습니다. 새 magic 모드는 스트릭트 모드에서는 자동으로 “strict mode only” 구문을 실행합니다.(Chris Dickinson) #1513
smalloc: ‘smalloc’ 모듈은 V8 4.4에서 사용할 수 없게 되므로 폐기될 예정입니다.
util: Promise, Map, Set 검사를 지원합니다.(Christopher Monsanto) #1471
V8: 4.2.77.18로 업그레이드했습니다. 자세한 내용은 변경 로그를 참조하세요. 주목할 만한 것들은 다음과 같습니다.
클래스가 스테이징 단계를 벗어났습니다. 이제 class 키워드는 스트릭트 모드에서 플래그 없이 사용할 수 있습니다.
객체 리터럴 개선이 스테이징 단계를 벗어났습니다. 이제 단축 메서드와 프로퍼티 문법을 사용할 수 있습니다. ({ method() { }, property })
Rest 매개변수(function(...args) {})가 스테이징에서 구현되었고 --harmony-rest-parameters 플래그로 사용할 수 있습니다.
연산을 사용한 프로퍼티 이름({['foo'+'bar']:'bam'})이 스테이징에서 구현되었고 --harmony-computed-property-names 플래그로 사용할 수 있습니다.
유니코드 이스케이프('\u{xxxx}')가 스테이징에서 구현되었고 --harmony_unicode 플래그로 사용할 수 있습니다. --harmony_unicode_regexps 플래그를 사용하면 정규표현식에서도 사용할 수 있습니다.
Windows:
Windows에서 무작위로 프로세스가 종료하던 문제가 고쳐졌습니다.(Fedor Indutny) #1512 / #1563
프로세스 이름(iojs.exe / node.exe)이 네이티브 애드온에 옵트아웃을 하는 문제를 고치기 위해 지연 로드 훅이 도입되었습니다. 네이티브 애드온은 문제가 있을 경우 이 기능을 끄려면 binding.gyp에 'win_delay_load_hook': 'false'를 포함해야 합니다.(Bert Belder) #1433
Governance:
Rod Vagg (@rvagg)가 Technical Committee(TC)에 추가되었습니다.
HTTP의 Request 혹은 서버의 Response, GC가 실행될 때 커널레벨에서 어떤 일이 벌어지는지를 추적하기 위한 기능이 추가되었습니다. 지금까지의 Node.js에서는 이것을 실행하기 위해서 Dtrace를 사용해 왔습니다만, Linux의 Dtrace 구현은 미숙해서, 모두 구현되어 있는 것이 아니었습니다. 결과적으로, Joyent가 제공하고 있는 SmartOS 같은 Solaris를 기반으로 한 Unix 환경에서만 Node.js가 Dtrace를 사용할 수 있도록 지원하고 있었습니다.
이제는 Linux 커널에서도 표준으로 트레이스가 가능한 LTTNG도 사용할 수 있게 되었습니다.
node의 커맨드에 --require 옵션으로 preload 모듈을 넘길 수 있게 되었습니다. (v1.6.0~)
1
$ node --require ./a.js b.js
사전에 preload해놓고 싶은 경우 사용할 수 있습니다.
process.nextTick에 여러 개의 매개변수를 넘길 수 있게 되었습니다. (v1.8.0~)
1 2 3 4 5 6
var obj = {};
process.nextTick(function(a, b) { assert.equal(a, 42); assert.equal(b, obj); }, 42, obj);
이 변경으로 인해, process.nextTick의 callback에 임의의 매개변수를 전달할 수 있게 되었습니다. API가 setTimeout과 setInterval과 비슷하게 되었습니다.
REPL에 history 저장기능이 추가 (v2.0~)
REPL의 magic mode라고 불리는 기능이 추가되어 있습니다. 이는 환경변수 NODE_REPL_HISTORY_FILE을 지정하는 것으로 REPL을 종료하더라도 다음 실행 시에 자신이 실행한 REPL의 내용을 기억해주는 기능입니다. 이른바 REPL의 history 저장 기능입니다.
Rest 매개변수가 --harmony-rest-parameters 옵션을 통해 사용할 수 있게 되었습니다.
harmony option에 Rest 매개변수가 추가되었습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// Rest parameters functionmax(...args) { // rest parameter is not Array-like object, that is just array. console.log(Array.isArray(args)) // true console.log(args.length) // 6
var max = args.reduce(function(max, n) { return n > max ? n : max; }); return max; }
현재, Google의 V8팀은 여러가지 시도를 하고 있는데, 그 중 StrongScript라 불리는 시도가 있습니다.
이것은, JavaScript의 자유도가 높은 구문(var, arguments, ==, delete, for-in 등)을 가능한 deprecated로 처리해서, ES6을 포함한 최신의 구문(let, …args, ===, Map, for-of)으로 바꾸기 위한 시도입니다.
이 StrongScript는 코드의 선두에, ‘use strong’ 디렉티브를 추가하는 것으로 Strong Mode가 되어, 실행됩니다.
마치 'use strict’를 통해 Strict Mode로 설정하는 것과 동일합니다.
이번의 io.js v2.0부터 Strong Mode가 --strong_mode 옵션 추가로 사용할 수 있게 되었습니다.
참고로 아직 실험적 시도이기 때문에, 실제 환경에서 사용하는 것은 권장하지 않습니다.
var ==> let/const
1 2 3
'use strong';
var a = 'hoge';
1 2 3 4 5 6 7 8 9 10 11 12 13 14
$ iojs --strong_mode strong_mode/vars.js
/Users/yosuke/iojs_v2_features/strong_mode/vars.js:3 var a = 'hoge'; ^^^ SyntaxError: Please don't use 'var' in strong mode, use 'let' or 'const' instead at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:411:25) at Object.Module._extensions..js (module.js:446:10) at Module.load (module.js:353:32) at Function.Module._load (module.js:308:12) at Function.Module.runMain (module.js:469:10) at startup (node.js:124:18) at node.js:882:3
arguments => …args
1 2 3 4 5 6 7
'use strong';
functionsome() { let args = Array.prototype.slice.call(arguments); }
some();
1 2 3 4 5 6 7 8 9 10 11 12 13
$ iojs --strong_mode strong_mode/arguments.js /Users/yosuke/iojs_v2_features/strong_mode/arguments.js:4 let args = Array.prototype.slice.call(arguments); ^^^^^^^^^ SyntaxError: Please don't use 'arguments' in strong mode, use '...args' instead at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:411:25) at Object.Module._extensions..js (module.js:446:10) at Module.load (module.js:353:32) at Function.Module._load (module.js:308:12) at Function.Module.runMain (module.js:469:10) at startup (node.js:124:18) at node.js:882:3
eqeq => eqeqeq
1 2 3 4
'use strong';
if ('a' == 'a') { }
1 2 3 4 5 6 7 8 9 10 11 12 13 14
$ iojs --strong_mode strong_mode/eqeq.js
/Users/yosuke/iojs_v2_features/strong_mode/eqeq.js:3 if ('a' == 'a') { ^^ SyntaxError: Please don't use '==' or '!=' in strong mode, use '===' or '!==' instead at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:411:25) at Object.Module._extensions..js (module.js:446:10) at Module.load (module.js:353:32) at Function.Module._load (module.js:308:12) at Function.Module.runMain (module.js:469:10) at startup (node.js:124:18) at node.js:882:3
$ iojs --strong_mode strong_mode/delete.js /Users/yosuke/iojs_v2_features/strong_mode/delete.js:5 delete obj.key; ^^^ SyntaxError: Please don't use 'delete' in strong mode, use maps or sets instead at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:411:25) at Object.Module._extensions..js (module.js:446:10) at Module.load (module.js:353:32) at Function.Module._load (module.js:308:12) at Function.Module.runMain (module.js:469:10) at startup (node.js:124:18) at node.js:882:3
for-in => for-of
1 2 3 4 5
'use strong';
for (let k in [1, 2, 3]) { console.log(k); }
1 2 3 4 5 6 7 8 9 10 11 12 13
$ iojs --strong_mode strong_mode/for.js /Users/yosuke/iojs_v2_features/strong_mode/for.js:3 for (let k in [1, 2, 3]) { ^^ SyntaxError: Please don't use 'for'-'in' loops in strong mode, use 'for'-'of' instead at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:411:25) at Object.Module._extensions..js (module.js:446:10) at Module.load (module.js:353:32) at Function.Module._load (module.js:308:12) at Function.Module.runMain (module.js:469:10) at startup (node.js:124:18) at node.js:882:3
폭넓은 환경의 지원(v1.4.0, v1.6.0, v1.8.0)
이번에, 상당히 빌드 환경에 기합이 들어가 있어, 폭넓은 환경에서 바이너리가 제공되고 있습니다.
Node.js였을 때는, darwin(osx), linux, sunos(solaris), windows의 바이너리가 제공되는 것뿐이었는데(그것만으로도 상당히 대단하긴 했지만), io.js부터는 ARM v6, v7을 포함해 상당히 많은 환경에서 바이너리가 제공되고 있습니다.
binary는 제공되지 않지만, Android에서 기동하기 위한 옵션이 있거나, SmartOS, FreeBSD에서 기동하기 위한 옵션이 제공되고 있습니다.
또 여러 OS의 가상 환경을 구축하고 그 위에서 테스트를 실행하고 있습니다. 어딘가의 환경에서 에러가 발생하면 즉시 알 수 있게 되어있습니다.
nan을 갱신하는 것만으로 가능한 모듈도 많기 때문에, 잊고 있는 모듈에 관해서는, 지금 nan을 갱신해서 풀 리퀘스트를 통해 알려주는 것이 좋지 않을까 하고 생각합니다.
다만 이번 v8이 갱신되는 것 만으로, 동작하지 않게 되는 모듈이 많으면 곤란하기 때문에, nan을 core에 넣자는 제안도 있습니다.
OpenSSL v1.0.2a가 되었습니다.
OpenSSL이 v1.0.2a가 되고, crypto의 성능이 개선되었습니다.
이 글이 자세히 설명하고 있습니다. [1]
빌드: 1.7.0을 출시할 수 없게 만든 Makefile의 문법 에러를 수정했습니다. (Rod Vagg) #1421.
C++ API: Fedor Indutny가 io.js에 포함된 V8에 있던 기능을 V8로 포팅했습니다. SealHandleScope를 사용하면 C++ 애드온 제작자가 HandleScope를 봉인(seal) 하여 애드온에서 발생하는 일어날 수 있는 의도하지 않은 할당을 방지할 수 있습니다. 현재는 io.js의 디버그 빌드에서만 사용가능합니다. 이 기능을 사용하면 #1075의 메모리 누수를 탐지할 수 있으며 현재는 io.js의 루트 HandleScope에서 활성화되어 있습니다. (Fedor Indutny) #1395.
ARM: 이번 릴리스에는 빌드와 테스트에 있어 ARM에 대한 지원이 대폭 개선되었습니다. io.js CI 클러스터의 ARMv6, ARMv7, ARMv8 빌드 서버가 (거의) 모든 빌드와 테스트를 통과했다고 보고하고 있습니다.
ARMv8 64비트 (AARCH64)를 이제 제대로 지원합니다. libuv에서 epoll_wait()의 존재 여부를 오판하던 문제에 대한 수정사항도 포함되었습니다. (Ben Noordhuis) #1365. ARMv6: #1376(라스베리 파이 포함)에서 Math.exp()를 사용할 때 문제가 발생한다는 보고가 있습니다. V8의 “fast math” 기능을 사용할 때 ARMv6의 잘못된 코드 생성기가 범인이었습니다. 이 문제를 피하기 위해 ARMv6에서는 —nofast_math를 기본값으로 사용하도록 했습니다. —fast_math를 사용하면 fast math 기능을 사용할 수 있습니다. (Ben Noordhuis) #1398. 테스트: ARMv6, ARMv7과 같은 느린 플랫폼에서 타임아웃 시간을 조정했습니다. (Roman Reiss) #1366.
npm: npm을 2.7.6으로 업그레이드 했습니다. 자세한 사항은 릴리스 노트를 참고하세요.
알려진 이슈
beforeExit 실행 중에 참조되지 않은 타이머가 실행되는 문제점이 있습니다. #1264 참고.
대화형 셸에서 서러게이트 페어(Surrogate pair)가 터미널을 정지시킬 수 있습니다. #690
process.send()는 문서에서 설명된 바와는 다르게 동기적이지 않습니다. 이 버그는 1.0.2에서 나타났었습니다. 문제에 대해서는 #760에서 확인 가능하며 #774에서 수정하고 있습니다.
DNS 쿼리 중에 dns.setServers()를 호출하면 실패한 단언문 때문에 프로세스가 중단될 수 있습니다. #894.
