ささきしき

チラシ

2021/3版「TypeScriptのenumを使うのはやめよう」追試

JavaScript のスーパーセットであるところの TypeScript には幾つかの固有構文があり、その中のひとつに enum があります。 例えば以下のように enum MOBILE_OS をおくと、以後のコードで MOBILE_OS.IOS などとして定数のように振る舞えるものです。

enum MOBILE_OS {
  IOS,
  ANDROID
}

const os: MOBILE_OS = MOBILE_OS.IOS;

ところがこの enum、複数の理由から「使わない方が良い」とされています。 細かい理由については本稿の先行エントリを読んでいただくとして、大きく2つの理由が挙げられることが多いようです。

  1. Tree-shaking できない
  2. Babel でトランスパイルできない(const enum の場合)

本稿は、この2点に関して、先行エントリを踏まえて現行バージョン(TypeScript 4.2.3, Babel 7.13.12)で追試をすることで、より新しい情報を世に残しておこうとするものであります。 ついでに何かやった気になるやつになります。イェイイェイ

検証環境

TypeScriptのenumを使わないほうがいい理由を、Tree-shakingの観点で紹介します - LINE ENGINEERING より引用、バージョンを本稿環境に揃えた

Babel の設定はデフォルトより以下を弄りました。

  • Source Type
    • Script から Module にした
  • PRESETS
    • react をオフに、typescript をオンにした

実験1 Tree-shaking するのか

サンプルコード(先述のサイトより同様に引用)

export enum MOBILE_OS {
  IOS,
  ANDROID
}

// 文字列を割り当てた場合
export enum MOBILE_OS {
  IOS = 'iOS',
  ANDROID = 'Android'
}

トランスパイルされたコード(https://www.typescriptlang.org/play より結果をコピー)

export var MOBILE_OS;
(function (MOBILE_OS) {
    MOBILE_OS[MOBILE_OS["IOS"] = 0] = "IOS";
    MOBILE_OS[MOBILE_OS["ANDROID"] = 1] = "ANDROID";
})(MOBILE_OS || (MOBILE_OS = {}));

// 文字列を割り当てた場合
(function (MOBILE_OS) {
    MOBILE_OS["IOS"] = "iOS";
    MOBILE_OS["ANDROID"] = "Android";
})(MOBILE_OS || (MOBILE_OS = {}));

結果1 Tree-shaking しない

f:id:sota_n:20210324193429p:plain

https://rollupjs.org/repl/ の実行結果スクリーンショット。先行エントリ同様、使っていないコードが残っている

実験2 バベれるのか

const enum を対象にするので、サンプルコードに若干手を入れます。

export const enum MOBILE_OS {
  IOS,
  ANDROID
}

// 文字列を割り当てた場合
export const enum MOBILE_OS {
  IOS = 'iOS',
  ANDROID = 'Android'
}

export const isIOS = (os: MOBILE_OS) => os === MOBILE_OS.IOS

結果2 バベれない

f:id:sota_n:20210324195650p:plain

https://babeljs.io/repl の実行結果スクリーンショット。未対応の旨エラー表示される

おわりに

今回参考にした先行エントリ2件はそれぞれ2020年の2月と7月のものであったので、半年も経てばなんか変わってないかな〜と思って追試の動機としましたが、残念なことに変化はなかった模様でした。 というか振り返ると、これは TypeScript というよりは Rollup と Babel の問題であるので、 TypeScript のメジャーバージョンが上がっていても関係ないと言われればごもっともかもしれない。

先行エントリにあるように、代替先としては Union Types があり、とはいえそれぞれに一長一短あるようなので、ユースケースに合わせて採用するのが良いのでしょう。なんでもケースバイケースって言えばいいと思いやがって!

個人的には困らない限り Union Types かな〜と思っています。 それはそれとして interface と type にもなんかこんな感じの話あったよなーとか思い出しました。また追試やるかもしれん。

参考(先行エントリ)

engineering.linecorp.com

www.kabuku.co.jp

言語野と戯れる

Mastodon を始めとする各種 Fediverse's SNS の中で、 :don: (末代とも)、mikutter、 およびその近辺でたむろしている零細・個人サーバ勢をここではひっくるめて雑にオタク共と呼ぶが、そのオタク共のなかで最近にわかに流行っているのが個人 bot である。 ある人物の発言(toot)を教師データにとって、任意の手法を用いて*1生成された文章を bot アカウントに発言させることで、予期されない面白い文章が生まれたりしたりしなかったりするのをなんとなく楽しんだりしている。

さて、そんな bot ブーム(?)であるが、おそらく、多分きっと、もしかすると、オタク共のなかで最初に bot の運用を始めたのは私ではないかと思っている。 これは勝手にそう思っているだけなので何の信憑性もないが、時にはそういう思い込みも必要だろうということで、第一人者(笑)として筆を取った次第である。

現在オタク共の bot で多く採用されている(と思われる)プログラムの源流は https://github.com/naaaaaaaaaaaf/mastodon-markov-bot である。 何を隠そうこれを書いたのが私——という訳ではなく、私は私で別なプログラムを用立てて使っている。 というのは、そもそも私が何のために bot を立ち上げたのか、という話になってくるので、そんな思い出話をしつつ、私が書いたコードを雑に紹介しつつ、今後 my new bot するオタク共のために雑に知見を残したり残さなかったりしようと思う。

*1:ほとんどがマルコフ連鎖を使っていると思う。

続きを読む

TypeScriptで自作型ファイルが読まれないときに確認するべき1つのこと

tsconfig.jsoninclude プロパティに型ファイルへの導線を足す


マストドンフレンドのねそねそ君がやってる「一人アドベントカレンダー Advent Calendar 2020」5日目の記事になりました。感謝。

adventar.org