まとめ
何がいいの?
・プレーンな JavaScript では得られない型のサポートを受けれるのでビジネスプロセスを取り扱う intra-mart と相性がいい
・スクリプト開発では速度を出したい時や小さなモジュールが多いけれど、後の人用に型とかの定義を残してバグの発生をはじく
反論
Java で書いたらいいやん
→ 仰る通りです…この辺りは改修案件なのかスクラッチで開発するのか、人員のスキルセットによりそうなので案件によって違いそう。
ただ、スクリプト開発は Rhino というエンジンで Java に変換しているので JS の対応バージョンが良くて ES5、ちょっと古いと ES3 なんですよね。Babel や TS 純正のポリフィル、トランスコンパイラが導入されることが望ましいと思います。
参考 Which JavaScript (ECMAScript) version does Java’s Rhino implementation implement (and what’s the update policy?)
そうなってくると型付きの TS 入れたらええやん!ってなります。
フレームワーク特有の関数でエラーが出るやん
→ そうなんです…もう intra-mart.d.ts をプロジェクト間で共有してインポートするしかないかなぁと思っています。公式から出ないかなぁ(チラッチラッ
ESLint の定義はあるんで、@type/intra-mart も出ると信じています。
導入
Node.js 入れる
Node.jsを取ってくる。
VSCode 入れる。
TypeScript といえばVSCode。軽いしオススメ。
eBuilder は.ts はプレーンなファイルとして認識するのでエディタの支援は受けれない。
npm 初期化する
プロジェクトルートで CLI で
npm init
をする。
拘りなければ全部エンターでいい。
TypeScript 入れる。
CLI で
npm i -g typescript
ファイルを.js から.ts に変更する。
型のみ利用する場合はトランスコンパイル後に元の js ファイルに戻る。
エラーがいっぱい出るので型を定義したりする。
イントラマート固有の定義は i-mart.d.ts に定義してインポートしてる。
/// <reference path=”i-mart.d.ts” />
コンパイルする。
CLI 上で
'''tsc ts ファイルパス'''
で同じディレクトリに ts→js ファイルにトランスコンパイルされる。
動いた! you win
型使っていこう!