ts-node は何者なのか
2024/12/26
はじめに
今日はちょっとしたツールを作るために TypeScript を使うことにした。
普段、JavaScript か TypeScript かでツールを作ってよいといわれたら JavaScript を使っていた。
理由としては、TypeScript のプロジェクトを一から作るのが面倒そうだからだ。
型がある方が楽だけど tsconfig とかの作り方を調べたくなかったのでそうしていた。
しかし GitHub Copilot が無料で使えるようになったので、立ち上げコストはかなり低い。
では TypeScript を使おうかという気持ちになる。
あ、私の場合はブラウザで実行するコードを書かないので node.js で動かす場合だけ書いてます。
ツールを作ったりするのだ。
ts-node
私が TypeScript のプロジェクトを作るときは、tsc でビルドする npm run build を用意していた。
動作させる環境で TypeScript のビルドというかトランスパイルをさせるのも面倒なので変換した JS ファイルをリポジトリに commit したこともあった。
そういう話を見ていくと、出てくるのが ts-node だ。
GitHub Copilot で生成してもらったプロジェクトも ts-node が使われていた。
私のこだわりというわけでもないし、うまく説明もできないのだが、プログラムを走らせるときはそれが最終的なものであってほしいと思っている。
バイナリファイルになって直接実行できる形式になっているなら、それが一番良い(個人の感想ね)。
tsc? typescript?
トランスパイラは tsc だったと思うが npm でインストールするのに typescript もあったはずだ。
どっちがどうなんだったか。
tsc は deprecated だそうな。
ただそれが typescript になったわけではなく、ntypescriptになっているらしい。
しかしこっちはこっちでメンテナンスは長いことされていない。
なので npm の tsc はもう考えなくて良いだろう。
babel?
babel っていうのも出てくる。
これは ReactNative で TypeScript を使っているときに出てきた。
元々はブラウザによって挙動が異なる部分を吸収するために作られたトランスパイラで、 プラグインによって TypeScript も処理できるようになっているというところかな？
ts-node は遅いのでは？
トランスパイラを使う場合、工程としてはトランスパイルと実行に分けられるはずだ。
トランスパイルした JavaScript のファイルがあるなら実行だけにすることもできる。
しかし ts-node を使った場合はそれをまとめて行うのだと思う。
トランスパイルしたファイルをどこに置いているのか分からないけどプロジェクトの中ではないようだ。
実行すると /tmp/v8-compile-cache-1000 というディレクトリが作られたからそれかと思ったが JavaScript のファイルはなかった。
めんどうなので ChatGPT氏に訊いてみるとメモリ上に作るだけでファイルにはしないということだった。
本当かどうかは知らないが、もうそれでいいや。
評価するためのツールだという回答も書いてあったが Overview にはそうは書いてないな。
node.js で動かすならトランスパイルが必要だし、RAM 上に全部展開するならメモリを圧迫するだろうし、あまり大規模なプログラムには向いてないと思う。
しかし node.js がどうファイルをさばいているのか知らないので、そっちも RAM に全部吸い上げてから実行するんだったらあまり負担にならない？ あるいは RAM の消費が倍になる？
など考えてしまったが、そもそもスクリプト言語にパフォーマンスを求めるような繊細さは私になかったよ。
jest はどうか
前に TypeScript で書いたとき、jest の動かし方が分からないのでトランスパイルしたファイルに対してテストしていた。
そういうときは ts-node を使えばよかったのだろうか？
babel か ts-jest らしい。
export していない関数のテスト
当時はそういえば rewire で private な関数をテストしたかったけど
ts ファイルは読み込めないのでトランスパイルした js ファイルを読み込んだのだったか。
export すればよいだけなのだけどそれもなんだかねぇ。
TypeScript で rewire する記事はあまり出てこなかったのだけど、そういうことをしたい人はどうしてるのか。
public にしたテスト用の関数を実装しているサイトがいくつかあったけど、ちょっとなんだかなあ。
テストは public なメンバーにするべし、という主張もあったがそこは人それぞれだと思う。 プロジェクトの中だったら意思は統一しないといかんだろうがね。