developersIO
cdk init の結果に要らない記述あるよなーと思って調べたら5年前のCDK初期の姿を垣間見た

cdk init の結果に要らない記述あるよなーと思って調べたら5年前のCDK初期の姿を垣間見た

「いらん記述を消せる話」をしようと思ったらエモい気持ちになった
FacebookHatena blogX
2022.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

※本エントリは、AWS CDK Advent Calendar 2022の２日目の記事となります。

親の顔より見たnpx cdk init app --language=typescriptですが、不要な記述や不要なライブラリが含まれています。

個人的には、余計な依存を消したりミスリードになりうる記述は消すようにしているので、それを紹介するとともに、

CDKの開発初期の5年前にさかのぼって、それらの不要な実装がどのような経緯で生まれたのかを追ってみます。

前提

cdk.jsonのappを見てわかるように、初期化されたcdkアプリケーションはts-nodeで動作します。

{
  "app": "npx ts-node --prefer-ts-exts bin/cdk-init-app-sample.ts"
}

https://www.npmjs.com/package/ts-node

cdkコマンドは内部でこのcdk.jsonを参照し、appに書かれたコマンドを実行します。

  • cdkアプリケーションはcdkコマンドを使って実行される
  • cdkコマンドはcdk.jsonのappを参照し、ts-nodeで実行される。

この2点を前提に、後述の修正を紹介していきます。

package.json

package.jsonの記述は、js,tsエンジニアにとって、そのアプリケーションの使い方を知る大きなヒントになります。

なのでpackage.jsonを使い方に合わせてシンプルにするべく、不要な記述は除去していきます。

bin

  "bin": {
    "cdk-init-app-sample": "bin/cdk-init-app-sample.js"
  },

npmのドキュメントにあるとおり、package.jsonのbinはそのアプリケーションをPATHに登録してcliから実行する場合に記述します。

binに記述されているbin/cdk-init-app-sample.jsは単体で実行しても何の効果もなく、cdkコマンドを用いてcdk.jsonから呼び出されて初めて機能します。

なので、このbinの記述は除去することができます。

scripts.build, scripts.watch

 "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
  }

ts-node を使っているのでtscを用いて.jsに変換する必要はありません。

dependencies.source-map-support

ts-nodeは、READMEに記載の通りもともとsource-mapを備えており、これによりCDK実行時のエラーのトレースログはtypescriptファイルの行番号を示すことができます。

ts-nodeがすでに実現してくれているので、追加でsource-map-supportを使う必要はありません。

後述の通りこのsource-map-supportはbinディレクトリのファイル内で使われているのですが、その記述含め、不要なので除去できます。

binディレクトリのファイル

先頭の2行、

#!/usr/bin/env node
import 'source-map-support/register';

が不要です。

  • 1行目のshebangは不要です。
  • source-map-supportも不要です（前述の通りts-nodeがもともとサポートしているので）

.npmignore

ファイル自体が不要です。npmパッケージとして公開する際に除外するものを指定するファイルです。

なぜ必要のない記述があるのか

歴史を紐解くと、これらのコードは5年前の2018年に生まれたのがわかりました。
当時のまだv0として開発していたcdkのコードを読んでみました。

https://github.com/aws/aws-cdk/tree/e2d2e8f16506d873b789fd06250c0d819f01a358

このときはまだcdk.jsonの仕組みを入れる前（cdk.jsonの仕組みが実装されるのはこの7日後）であり、かつts-nodeは採用されておらず、cdk deployに--app=bin/app.jsのようにオプション指定することで、synthesizeを実行していたようです。

そのため、binディレクトリのtsファイルはtscによってjsファイルにコンパイルする必要があり、加えてshebangを与えておくことで--appの指定を簡略化していたようです。

package.jsonのbinは、他の人が作成した便利cdk実装（例えばawesome-cdk-appのようなライブラリ）を、cdk deploy --app='npx awesome-cdk-app'のように実行できるようにinit templateに用意されていたと思われます。

現在では--appの指定はできるもののcdk.jsonで予め指定するのが一般化しており,かつts-nodeが採用され、便利cdk実装の再利用はconstruct hubで公開されたものをconstructとして組み込むのがあたりまえになっています。

まとめ

「この実装いらんよなぁ」と思って脳死で除去していた実装の経緯を探ったら、CDKの超初期のプロトタイプ実装を垣間見ることができ、エモい気持ちになりました。

この気持を共有すべく、アドベントカレンダーの2日目として紹介させていただきました。

以上です！

この記事をシェアする

FacebookHatena blogX