React.jsで、無駄に時間を使ってしまった、つまらないミスやハマったことについてメモを残すのです。
繰り返される悲しみも、悪い夢も、きっと終わらせられる。
jestでテスト実行するとsegmentation fault
$ npm test
...
Using Jest CLI v0.4.0
Waiting on 1 test...zsh: segmentation fault npm test
実はインストール時に警告がでていたのですが、Jestはnode 0.8/0.10系にのみ対応しており、0.12系で実行するとsegmentation fault
が発生します。
$ npm install jest-cli
npm WARN package.json @ No description
npm WARN package.json @ No repository field.
npm WARN package.json @ No README data
npm WARN engine jest-cli@0.4.0: wanted: {"node":"0.8.x || 0.10.x"} (current: {"node":"0.12.1","npm":"2.5.1"})
...
issueによると古いjsdom(0.10.6)に依存している部分を新しいバージョンに対応させる必要があるようですが、jsdom自体の更新速度が速いのと、4.x系からnode.jsを捨ててio.js専用になってしまったのもあり、どのバージョンに上げるかで悩ましさがありそうです。
nvm
ではなくnodebrew
使っているので、ローカルのモジュールインストールとテスト実行時だけ0.10系に戻したりとかやっていますが、あまり有効な解決策は思いついていないのでまだ面倒です。
syntasticでObject Rest Destructuringがエラーになる
Vimのシンタックスチェッカsyntasticの話。
syntasticのデフォルトでは、JavaScriptの構文チェックにJSHintを使うようになっていますが、DestructuringのようなES6構文に対応するにはesnextオプションが必要です。syntastic経由でオプション渡す方法がすぐに見つからなかったので、どのみちJSXなども使うのだからとESLintに切り替えます。
ESLintをインストール。
babelify --experimental
なんかを使う覚悟の人は、.eslintrcのecmaFeaturesを全てtrue
で記述してしまうと良いです。
$ npm install -g eslint
.vimrcのJavaScriptチェッカをeslintに変更します。
let g:syntastic_javascript_checkers = ['eslint']
ところが、JSXのSpread Attributesは独自拡張によりObject Rest Destructuringに対応していて、これがESLintではUnexpected token ...
としてエラー扱いになってしまいます。
// ObjectのRest DestructuringはES7のproporsalなので非対応
// a -> "hoshimiya"
// z -> { b:"oozora", c:"arisugawa" }
var {a, ...z} = { a:"hoshimiya", b:"oozora", c:"arisugawa" };
// 配列はES6から使える
// a -> 1
// b -> [2, 3]
var [a, ...z] = [ 1, 2, 3 ];
そこで、Babel提供のラッパパーサであるbabel-eslintにパーサを切り替えます。
$ npm install -g babel-eslint
ドキュメントに従って、.eslintrc
のparser
にbabel-eslint
を指定します。
{
"parser": "babel-eslint",
"rules": {
"strict": 0
}
}
一応、下記のような注意書きがあるけれど、今のところ特に問題があるようには感じていません。.eslintrc
のecmaFeatures
は未設定でも動作するので、もう参照していない感じがします。
NOTE: Please note that this is experimental and may have numerous bugs. It is however successfuly linting the babel core.
TestUtils.findRenderedDOMComponentWithTag でエラー
これはドキュメントよく読まずに使っていたのが問題ですが…
$ npm test
...
Error: Did not find exactly one match for tag:xxxxx
findRenderedDOMComponentWithTagは結果が1件のものを探して返すメソッドで、結果複数あると上記のようなエラーで中断されます。findRenderedDOMComponentWithClassなども同様。
複数要素を配列で返して欲しい場合には、scryRenderedDOMComponentsWithTagを使うのでした。
CSSTransitionGroupを使おうとしてUncaught TypeError
var ReactCssTransitionGroup = React.addons.CssTransitionGroup;
こんなコードを書いていたら、謎のUncaught TypeErrorが発生する事例。
Uncaught TypeError: Cannot read property 'toUpperCase' of undefined
CssTransitionGroup ではなくて CSSTransitionGroup だという…
reactifyを実行するとError: EMFILE
$ browserify -t reactify main.js -o bundle.js
Error: EMFILE, open '/tmp/exmaple/node_modules/react/package.json'
これは特に時間かかったわけではないけれど、EMFILE(Too many open files)
なのでファイルディスクリプタの上限をulimit
で増やすなどして回避します。Mac OSXでは初期値が256と少なめだったので、発生しやすいかもしれません。
$ ulimit -n
256
$ ulimit -n 512
永続的に反映させる設定は環境ごとに異なるので、別途でご確認ください。
reactify固有の問題でもないので、内部で多めにスクリプトロードしそうな他のtransform(babelifyとかも?)を指定した場合などでも発生するかもですが、発生頻度もそんなに高いわけではないのであまり気にしていないです。
その他
何かあったら追加します。