Today we’re launching Test262 Report to provide JavaScript developers with up-to-date information on the state of new and existing language features across implementations. Test262 Report is based on daily runs of Test262, the ECMA-262 (“ECMAScript” or “JavaScript”) test suite, in nightly builds of JavaScript engines, and visualizes at-a-glance status of feature implementation progress. Taking a l
MarAprMayJunJulAugSepOctNovDecJan 2020FebMarAprMayJunJulAugSepOctNovDecJan 2021FebMarAprMayJunJulAugSepOctNovDecJan 2022FebMarAprMayJunJulAugSepOctNovDec
In the beginning of 2015, we started another important project for the open web. Of course you haven’t forgotten, but for all the folks just joining us:Google and Bocoup teamed up to improve Test262, the official test suite for the JavaScript language. Our goal was to improve the dependability of the web platform (not just the V8 engine) as a base for application development. We focused on improvi
This project includes a console runner to facilitate running tests from console hosts. I understand that some folks at Mozilla rely on it in some capacity (@tschneidereit may be able to give more detail), and the V8 team uses some of its internals in their own Python-based runner. TC-39 agreed to deprecate the runner in 2014. This decision wasn't well-communicated, so there was some contention a f
I'm reluctant to accept this. On the one hand, I love tests, and more tests might catch more bugs. But there are a few other concerns that give me pause. First, there's the issue of validation. As the official test suite for the ECMAScript specification, correctness in Test262 is critical. I fully expect that you've done the legwork here, but the maintainers of this project have to heed Reagan's a
I'm interested in formalizing the contract between Test262 and the implementors who maintain harnesses to execute it. For instance, implementors currently have to infer that: most tests rely on a file named harness/sta.js. some tests mutate global state so as to make realm sharing unacceptable test code must be evaluated in the global scope I expect we will see more benefit from a document like th
ES6 で書かれたコードをユニット テストしたい。できればテスト自体も ES6 で。という希望を実現してくれそうなツールがあったので試してみる。 mocha ユニット テストには mocha を利用する。業務で Node モジュールのテストに利用していて馴染みがあるのと後述する espower-babel が mocha を想定しているのがその理由。 mocha を npm test や npm run から利用するならインストールはローカルだけでよい。package.json 管理下にある npm にはパスが通った状態になる。 余談だが以下の記事を読んで gulp などもローカルにインストールして実行を npm で抽象化するほうがよいのでは?と考えるようになった。 npm で依存もタスクも一元化する 記事中にもメリットとして説明されているとおり利用者は npm だけ覚えればよい。グローバ
Stabilizing ECMAScript 2015 (ES6): Teaming up with TC39 and Google on Test262 Posted by Mike Pennisi August 14, 2015. Mark your calendars. That’s my next birthday. Another important date is June 18, 2015–it’s when the ECMA General Assembly will vote on and approve the 6th edition of Ecma-262 and usher in the next era of JavaScript. On that day, all those new language features we’ve been coveting/d
この記事はECMAScript 2015の事始めとして、ライブラリをECMAScript 2015で書いて公開するというところから始めるのがいいのではという内容です。 ECMAScript 2015(ES2015)はES6とも呼ばれていてどちらも同じものを指しますが、この記事ではES2015に統一します。 ECMAScriptのバージョンについては次のページを参照してください。 ECMAScript · JavaScriptの入門書 #jsprimer 2018-12-27: 追記 textlint/textlint-rule-helperのmasterはTypeScriptの実装へ変換されています。 Babelの実装はhttps://github.com/textlint/textlint-rule-helper/tree/2.0.1から参照できます Babel から TypeScrip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く