LoginSignup
20

More than 5 years have passed since last update.

WindowsにTypeScript開発環境を整えた覚え書き

Posted at

ろくにWindowsもWeb開発も触ったことがなかった筆者がWindows環境でTypeScriptアプリケーション(Webページ)を書くことになったので、そのために環境構築した覚え書きを残しておく。この分野は初めて触るので、文化的な誤りなどが大いに含まれている可能性がある。このドキュメントの正しさは保証しないが、「ここ間違ってんぞ」という指摘を頂いた場合はすみやかに修正する(と思う)。

始める前に入れておくと良いツール

  • Chocolatey

    • Windows向けのパッケージ管理ツール。Chocolateyの神があなたの要求に答えてくれる(原文ママ)
    • VSとかgitとか一発で入れられるので使ったほうが良いと思う
    • https://chocolatey.org/
  • ConEmu or Cmder

コンパイラのインストール

tsc - Type Script Compilerはnpmを使ってインストールするので、まずはnode.jsを導入する。chocolateyを使う場合は管理者権限で以下のコマンドを実行する(パッケージ名は変わるかもしれないので、実行前にsearchすること)。

    choco install nodejs

node.jsがインストールされ、npmコマンドが存在するのを確認したら、次のコマンドを実行する。

    npm install typescript

すると、$HOME/node_modules/.binの下にtscという名前のファイルが出力されているはずなので、実行してバージョン情報などが出力されていればインストール成功である。

IDEの設定

TypeScriptを記述する上でIDEは必須ではないが、せっかく静的に型がつくのだから、IDEを使ったほうが幸せになれそうな予感がする。

VisualStudio (Microsoft)

VisualStudioを使う上では、これといった設定は必要ないので、操作する手間としては一番小さい…が、インストールに時間と容量を大量に消費する。Chocolateyで入れると多少楽。

VisualStudioでTypeScriptアプリケーションを開発するにはWeb開発用のコンポーネントが必要になるので、すでにコンポーネントを外してインストールしてしまっている場合は、インストーラからコンポーネントを追加する必要がある。TypeScript型定義ファイルもVisualStudioのパッケージ管理で入れられるので良い。

WebStorm (JetBrains)

WebStormはとても優秀なIDEなので、ガッツリ書くならこちらを使うほうが良いと思う。ただしこれは有償なので、ライセンスを購入する必要がある。とりあえず30日間は評価版として利用できるので、ちょっとした修正程度なら触ってみるのも良いかもしれない。Chocolateyのパッケージは古い(2015/03/17現在)ので、手動で導入したほうが良いかもしれない。

WebStormを使うのであれば設定が多少必要になる。重要なのは、FileWatcher(WS10からは消滅するらしい)の定義でインストールしたコンパイラへのパスを通すことと、コマンドラインオプションとして--target ES5を指定することである。

WebStormの利点として、かなり強力なデバッグ機能が挙げられる。Chromeにデバッガプラグインを入れることで、WebStorm上からChromeのデバッグができるようになる。

その他

たとえばEmacsなどにもTypeScript用のモード(MELPA/tss)はあるので、そういったものを使って記述することもできる。その際は -w オプションを tsc コンパイラに渡してやると、自動的にファイルの変更を監視してコンパイルしてくれるので便利である。また、WebStormの時と同じように --target es5 を指定するのを忘れないこと。

デバッグ用Webサーバ

ローカルで立ってるテストサーバに他の端末からアクセスして動作を確認するためには、Windowsファイヤーウォールを設定してポートを開ける必要があるので、これを忘れないこと。IDE付属のウェブサーバはあまり使い勝手が良くないので、npmからkokoという簡易サーバのパッケージを導入したら便利だった。

    npm install koko

tscと同じディレクトリにkokoという実行ファイルが生成されるので、パスを通す。あとはルートディレクトリにしたい場所で以下のコマンドを実行するとサーバが起動する。

    koko -P 8080

-Pオプションはポート番号の指定で、これを指定しないと使われていないポートからランダムな番号が使用される。ファイヤーウォールとの兼ね合いもあるので、できれば明示するほうが良いだろう(localhostだけで完結するなら必要ないが)。

Tips

  • 外向きにHTTPサーバを起動できない時は、次の項目をチェックすると問題が解決するかもしれない
    • Windowsファイアウォールで目的のポートが開いているかどうか
    • 既に何かのプロセスが目的のポートを専有していないかどうか(netstatコマンドを使う)
    • 心当たりが無いにもかかわらず80番もしくは443番が使えない場合は、Skypeが怪しい。
    • [設定] -> [詳細設定] -> [接続] から「追加の受信接続ポートに…」のチェックをはずす

ドキュメンテーション

JavaDoc的なドキュメントコメントをソースコード中に記述することで、JavaDoc的なドキュメントをHTMLで出力してくれるツールがいくつかある。それぞれに特徴があるので、プロジェクトにあったものを使えば良い。TypeScript界での勢力図はよく知らないので、選定するにあたって触った感触を記録しておく(私は最終的にはTypeDocを使うことにした)。

JSDoc

JavaScript界隈では最も使われているように見える。少なくともTypeScript Language Specificationにも名前くらいは出てくる。が、本質的にはJavaScriptにドキュメントを付帯させるためのものなで、TypeScript-JavaScript間の概念の違いが壁として立ちはだかる。

具体的にはインターフェースなどのTypeScript特有の概念がネックで、JavaScriptにトランスパイルするときに消滅する宣言に付属しているドキュメントコメントは消滅する。これは現在のTypeScriptコンパイラの挙動によるもだと思うので、将来的にどうなるかはわからない。仕様書を読んでもよくわからなかった。少なくとも現状JSDoc側からは何ともできないのは間違いないだろう。

また、JavaScript用のタグだけではTypeScriptの概念をドキュメントしきれないのではないかというのがあって、正直言ってどのタグを何に書けばいいのかがよくわからない(トランスパイルすると移動したりするし)。そういう意味で、TypeScriptとの親和性はあまり高くないのかもしれない。 

YuiDoc

YuiDocはTypeScriptのソースコードを直接読み込ませることができるので、JSDocよりは扱いやすい。少なくとも宣言に引きずられてコメントが消滅したりはしない。ただ、TypeScriptのmodule直下に生えてる関数の所属がGlobalになったり(正しい挙動じゃないよね?たぶん)、細かい部分に粗が目立ったりする。あと、モジュールやクラス階層が重なっていくと、メソッドの名前をドキュメントに定義するのも一苦労(YourModule.YourClass.YourInnerClass#methodNameみたいな感じ?)なので、あまり書きやすくない印象を受けた。

TypeDoc

TypeDocは最初からTypeScriptに作られているようなので、前者2つよりもTypeScriptとの親和性が高い。ソースコードの解析もやってるようなので、ドキュメント書いてないメンバも取り敢えず出力される。また、型もすべて推論されるし、メンバのクラス名も書かなくても正しく出力されるので、記述が楽である。これといって理由がなければ、TypeDocを使うのが無難という印象を受けた。

--modeオプションがよくわからなかったが、"--mode file"を指定しておけば良いと思う。ほかはデフォルトでなんとかなるんじゃないだろうか。

オススメ参考情報

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
20