intra-martのロジックをTypeScriptで書くメリット

2020年05月26日 00時05分

まとめ

何がいいの?

・プレーンな 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

型使っていこう!