作りたいもの: JavaScriptのコードの質を保つためのガードレール

増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったので早速やってみました。3つ目。

JavaScriptのコードの質を保つためのガードレール

JavaScriptは柔らかい言語で、typoとか変数名の変え忘れが実行時までエラーにならない。しかもしれっとundefinedとかになって、そのままHTMLやSVGのpath文字列に埋め込まれてたりしてデバッグにコストが掛かってしまう。人間は間違える生き物だから、間違いをなくすことはできない。だから間違えた時になるべく早く気づけるようにする仕組みが必要だ。


Google Closure CompilerはJavaScriptのソースコードを静的に検証してエラーを報告してくれる。であれば自分がソースコードを編集している時にバックグラウンドでがんがんコンパイルしてエラーが見つかり次第報告してくれればいいんじゃないか。

jscc: JavaScript Continuous Compilation

実は既に作って公開してある。http://nishio.github.com/jscc/

ファイルを編集するとwatchmedoでGoogle Closure CompilerとLintが実行され、グラフが自動更新される。コンパイルエラーがあれば赤、警告があれば黄色、両方なければ緑になる。僕がJSでコードを書く際には、デュアルモニターの端っこでこれを表示して、普段は注視しないでコードを書いていて、赤や黄色に変わると視野の端にあっても色が変わったことに気づくのでエラーログを確認する、というやり方をしている。

問題点

  • インストール周りがひどい。プロジェクトのルートディレクトリに3つシンボリックリンクを作るだけ。しかもそのうち1つはMakefile。
  • コンパイル結果とLintの結果がプロジェクトルートのcompile.logとlint.logに作られる。コンパイラが多重起動しないためのロックファイルもそこに作られる。プロジェクトを汚しまくりなのでこれは別のところにおいたほうがいいと思う。
  • watch周り
    • Windows(cygwin)だとwatchmedoがうまく動かないという報告があった。
    • 現状、watchしているプロセスを殺す方法がない。どうするのがよいか？
    • watchmedoを使っていると、git statusやgit add -pでコンパイルが始まってしまう謎
    • →いっそwatchmedoを使うのは辞めて、Pythonでファイルの更新日時を定期ポーリングするコードを書いた方がよい？
  • クライアントツール
    • Makefileとbuild.shとclient.pyをカレントディレクトリにln -sする設計になっているけど、そもそもプロジェクトの内容に応じて書き換える必要があるのはMakefileだけだから残りの2つはjscc/client/に置きっぱなしでいいんじゃない？compile.logとlint.logもjsccの中に作ったほうがいいんじゃない？なるべく汚さない方針で。
    • flymakeと統合？エラーの行をemacs上で表示したら幸せになれる？
    • 将来的に複数のプロジェクトで複数人で使う際には識別のためにプロジェクト名とユーザ名を送る必要がある。今は一人で使う想定でシングルユーザ・シングルプロジェクト
    • growlnotifyは必須ではないので(僕は使うけど)インストールされてるかどうか判断して使うようにしたいがどう書く？
  • 可視化サーバ
    • 今はシングルユーザ・シングルプロジェクトなのでトップページでそのままグラフが見えるけど、将来的に複数のプロジェクトと複数人で使う場合にはトップページはプロジェクト一覧にして /project_name/nishio/ みたいなURLで見るようにするべき
    • いま過去の履歴を保存していない。sqliteかなんかで保存しておく。最新n件を取るAPIが必要。
    • 今はJSで1秒1回サーバにポーリングしているが、タイムアウトしてないせいでサーバが止まっているとリクエストが溜まってしまう？どうするのがよい？Comet？