Node.js × TypeScript 勉強中

TypeScript Node.js JavaScript

Node.js × TypeScript の勉強中。いずれも触るのはほぼ初めてです。各種チュートリアル記事を読んで試していますが、「このおまじないは何？どっからきたの？」状態なので、今回疑問に思ったことがそれぞれがどの文脈に帰属する問題なのか (Node.js / TypeScript あるいは他のなにか) をまとめました。

こういう、新しいものを学ぶときの手探り感を大事にしていきたい。

知っていたこと

  • Node.js はサーバーサイドで動く js だよ
  • TypeScript をコンパイルすると JavaScript になるよ； pure js と違って型があるよ
  • npm はパッケージをいい感じにインストール・管理してくれるやつだよ； 設定は package.json に記述するよ

export / import ってなんやねん

MyApp.js

export class MyApp {
  doSomething(){
    ...
  }
}

app.js

import {MyApp} from './MyApp'

let app = new MyApp();
app.doSomething();

export / import は ES6 (もともとは CommonJS で生まれたらしい) で既定される構文で、 js ファイルをまたがってモジュール (変数や関数) を利用したい場合に使用します。サーバーサイド js の繁栄に伴いモジュール管理の重要性が高まってきたことによって導入された構文のようです。従来のワークアラウンドとしては、グローバルに名前空間を切って擬似的にモジュール化を実現するという手段がありましたが、依存関係を解決できませんし、グローバル汚染はやはり発生してしまっていました。 export / import によって、これをスマートに実現できるようになったわけですね。

経緯については こちらの記事 で大変わかりやすく書かれています。

typings ってなんやねん

Node.js × TypeScript のチュートリアル記事でよく登場するのが以下のおまじないです。

npm install -g typescript
npm install -g typings

typescript はわかるとして typings はなんでしょうね。これは TypeScript の型定義を管理してくれるツールのようです。何もしないと TypeScript が Node.js の型を解釈できないわけですが、 typings install dt~node のようなコマンドによって、TypeScript のコンパイルが通るようにしてくれます。

型のインストール設定は typings.json に書きます。なので git 管理するときはこいつを突っ込んでおけば良いようです。

一方で、 typings を使わない記事では以下のようなおまじないが登場していました。

npm install @types/node --save

調べてみると、 @types も TypeScript の型定義を管理してくれるようです。こちらの方が新しいんですね。package.json に追加するだけでよく、 typings のインストールや typings ファイル群 / typings.json を管理する必要がないため、シンプルに済みそうです。ただし、 TypeScript の中の人の記事 によれば this is still a work in progress. だそうですから、このあたりのエコシステムはまだ変わる可能性がありそうです。

typings 以前には tsd というものもあったらしいですが、もはや非推奨らしいので触れません。

npm install -g ってなんやねん

↑でも登場していました。npm install のオプションであることはひと目でわかりますが、多くのインストールのインストラクションで指定されています。

g は global を意味するようで、どこで実行してもパスが通るようにするためのものです。 windows であれば /appdata/Roaming/npm に配置されるようですね。

世間では高い頻度で使用されるオプションですが、できるだけ使いたくない派 の方もいらっしゃるようです。たしかに、ローカルで動いてたけど別の環境で動かなくなった、ということでハマることは容易に想像できますねー。

use strict ってなんやねん

TypeScript をコンパイルすると、生成された js ファイルの先頭行に "use strict"; が登場します。これは ES5 以降の規格で、指定すると js の構文チェックがより厳格に行われるようになるらしいです。

pure js でも、将来の ECMAScript への移行をスムーズにするため等の目的で、積極的に利用していきたいですね。

tsc はどこで実行するんじゃい

tsc は TypeScript のコンパイルを行うコマンドです。プロジェクトのルートで npm とか叩いてて、ソースは src ディレクトリの中にいる、みたいなときにルートでひたすら tsc 実行してて、「ヘルプしか出てこないやんけ！」と騒いでいましたが、ソースと同じディレクトリで実行する必要がありました。まあ当然なんですけど。

ターミナルでわざわざルートとソースのディレクトリを行き来するのはクソ面倒ですしオペミスのもとなので、 npm のスクリプトに追加しとくのが良いんでしょうね。

{
  "scripts": {
    "build": "tsc -p src"
  }
}

(-p オプションで実行ディレクトリを指定できる)

セミコロンは要らんのかい

各種チュートリアル記事で Node.js / TypeScript の行末セミコロンが無いコードが沢山ありました。 JavaScript には自動セミコロン挿入という機能があるが害悪である、というのが一般的な認識だと思っていたので、こっちの世界では書かないのか正しいのか？？と困惑しました。

これは結果的にはたまたまだったようです。セミコロンが無いほうが読みやすい、というのもわからなくはないですが、Node.js のコアコントリビューターであるFelix Geisendörfer 氏はセミコロンつけろと言っています。つけなくても大丈夫であるという確証は得られてませんが、好みの問題なのでしょうかね。

というわけで Node.js の実際の部分とかには全然踏み込めてないわけですが、そのへんは回を改めましょうかね。