この記事はタイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜の5日目の記事です。自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

TypeScript+Jestでテストを書くときに型安全にモックする方法を教えてほしかった

TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっています。 
外部にコードが保存されるという訳でもないので、どういう仕組みで共有が実現されているか気になったので、調べてみました。
<h2 id="仕組み">仕組み</h2>
仕組みとしては以下の流れでURLを通してコード共有がされていました。
<ol>
<li>エディターに記述してあるコードを文字列圧縮ライブラリで圧縮</li>
<li>URLに圧縮した文字列を挿入</li>
<li>URLを開くときに圧縮された文字列を展開してエディターにコードとして表示する</li>
</ol>
<h2 id="コードの文字列圧縮">コードの文字列圧縮</h2>
コードの圧縮処理は<a href="https://github.com/microsoft/TypeScript-website/blob/1e7ea49f60953aa446b591c6aff347a7c566e3cb/packages/sandbox/src/compilerOptions.ts#L85" target="_blank">ここのコード</a> で処理がされており、<a href="https://pieroxy.net/blog/pages/lz-string/index.html" target="_blank">lz-string</a> という文字列圧縮ライブラリが使われていました。
<pre class="language-typescript"><code class="language-typescript"> const hash = `code/${sandbox.lzstring.compressToEncodedURIComponent(sandbox.getText())}`
</code></pre>

TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっている。その仕組みを調べてみました。

TypeScript Playground のコード共有の仕組み

先日、TypeScriptのテンプレートリテラル型を使う機会がありました。
<h2 id="モチベーション">モチベーション</h2>
フロントエンドで i18n を導入するために <a href="https://github.com/i18next/i18next" target="_blank">i18next/i18next</a> を利用して文字列の辞書対応を進めていました。
辞書ファイルを入れ子のオブジェクトとして定義ができますが、キーを指定する場合は <code>common.badge.required</code> と指定する必要があります。TypeScripeで実装をするときの問題として、キーの文字列に対して型チェックが有効にならないため、タイポをしても気づかない問題があります。
<pre class="language-typescript"><code class="language-typescript">import { t } from 'i18next';

const translation = {
 common: {
 badge: {
 required: '必須',
 optional: '任意'
 }
 }
}

export const resources = {
 ja: {
 translation: translation,
 },
} as const;

i18n.init({
 lng: 'ja',
 resources: resources,
})

// badge => bage とタイポしているが実行時まで気づけない
console.log(t('common.bage.required'));
</code></pre>
<h2 id="テンプレートリテラル型で型定義">テンプレートリテラル型で型定義</h2>
この問題はテンプレートリテラル型を活用してオブジェクトからキーを <code>.</code> で繋いだリテラル型を生成することで解消することができます。
<code>FlattenKeyOf</code> のユーティリティ型は型引数としてオブジェクトの型を受け取り、Mapped Types を利用してキーの一覧を取得します。取得したキーに対応する値の型を Conditional Types で判定しオブジェクト型である場合は、キーを <code>.</code> で先頭に結合して、対応する値のオブジェクトを <code>FlattenKeyOf</code> の型引数に渡して再帰的に呼び出すことで残りのキーを文字列として結合します。値がオブジェクトでない場合はキーをリテラル型として返します。
<code>string &amp; K</code> と書いている部分は <code>K</code> が <code>string | number | symbol</code> 型として扱われますが、テンプレートリテラル型が受け付ける型はプリミティブ型となっているため、型のミスマッチが発生してエラーが発生するので、Intersection Types を利用して <code>string</code> 型であれば <code>K</code> を返し違う場合は <code>never</code> を返すようにすることで型のエラーを回避しています。
<pre class="language-typescript"><code class="language-typescript">// const translation = { link: { top: 'トップページ' }}
// type keys = FlattenKeyOf&lt;typeof translation> = 'link.top'
// FlattenKeyOf&lt;{link: { top: 'トップページへ' }}> = {
// ['link']: `link.top` &lt;= `link.${FlattenKeyOf&lt;{top: 'トップページへ'}}`
// }['link'] ^
// |__ 'top' = FlattenKeyOf&lt;{top: 'トップページへ'}> = { ['top']: 'top' }['top']
type FlattenKeyOf&lt;T extends Record&lt;string, unknown>> = {
 [K in keyof T]: T[K] extends Record&lt;string, unknown> ? `${string &amp; K}.${FlattenKeyOf&lt;T[K]>}` : string &amp; K
}[keyof T]

// common.badge.required | common.badge.optional
type ResourceKeys = FlattenKeyOf&lt;typeof messages>;

// 引数のキー文字列が辞書ファイルのキー文字列のユニオン型に限定されるため、型チェックでエラーとなる。
console.log(t&lt;string, ResouceKeys>('common.bage.required'))
</code></pre>

TypeScriptのテンプレートリテラル型の利用例を紹介します。

TypeScriptのテンプレートリテラル型の利用例

tsconfig.json には <a href="https://www.typescriptlang.org/ja/tsconfig#skipLibCheck" target="_blank">skipLibCheck</a> という設定オプションがあります。 
このオプションの挙動やどんな時に設定するかについてまとめました。
<h2 id="skipLibCheckの挙動">skipLibCheckの挙動</h2>
このオプションのデフォルト値は false で true を設定することで <code>*.d.ts</code> ファイルに対する型チェックをスキップすることができます。
次のようなサーバーのコードを考えてみます。
<pre class="language-typescript"><code class="language-typescript">import express from "express";

const app = express();

app.post("/uses/sign_in", (req: express.Request, res: express.Response) => {
 if (req.tokens.includes('abc')) {
 res.sendStatus(200)
 } else {
 res.sendStatus(403);
 }
});

app.listen(3000, () => {
 console.log("Listening on port 3000");
});
</code></pre>
tsconfig.json では <code>skipLibCheck</code> は定義しておらず、デフォルトの false が設定されている状態です。
<pre class="language-json"><code class="language-json">{
 "compilerOptions": {
 "esModuleInterop": true,
 "typeRoots": [
 "node_modules/@types",
 "types"
 ]
 }
}
</code></pre>
<code>req.tokens</code> は次のような型定義ファイルを作成して、 <code>express.Request</code> の型定義を拡張して新たにプロパティを定義しています。この時、 <code>tokens: Array</code> とジェネリクスを指定すべき箇所を誤って指定しているため、型定義エラーが発生しています。
<pre class="language-typescript"><code class="language-typescript">// types/express/index.d.ts
/// &lt;reference types="express" />

// @see: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/method-override/index.d.ts
declare namespace Express {
 export interface Request {
 // Interface Array&lt;T>
 // Generic type 'Array&lt;T>' requires 1 type argument(s).ts(2314)
 tokens: Array;
 }
}
</code></pre>
この状態で、 tsconfig.json にて <code>skipLibCheck: true</code> を設定します。
<pre class="language-json"><code class="language-json">{
 "compilerOptions": {
 "skipLibCheck": true,
 // (省略)
 }
}
</code></pre>
<code>*.d.ts</code> ファイルに対する型チェックがスキップされるのでエラーが消え、正しくない型定義ファイルが存在してもコンパイルエラーが出なくなってしまいました。
<pre class="language-typescript"><code class="language-typescript">declare namespace Express {
 export interface Request {
 tokens: Array;
 }
}
</code></pre>
この状態では <code>req.tokens</code> は <code>any</code> として解釈されます。
<pre class="language-typescript"><code class="language-typescript">// （省略）
app.post("/uses/sign_in", (req: express.Request, res: express.Response) => {
 // (property) Express.Request.tokens: any
 if (req.tokens.includes('abc')) {
 res.sendStatus(200)
 } else {
 res.sendStatus(403);
 }
});
</code></pre>
<h2 id="skipLibCheckのメリット">skipLibCheckのメリット</h2>
挙動を見る限りでは <code>skipLibCheck: true</code> を設定することで、型チェックの精度が下がるデメリットがありましたが <code>skipLibCheck: true</code> を設定するメリットは何なのでしょうか？
アプリケーションが中規模、大規模になり依存するパッケージが増えた時に、それに比例して型定義ファイルが増えていきます。 <code>tsc</code> のデフォルトの挙動では、TypeScriptをコンパイルするときに <code>@types/express</code> などのライブラリの <code>*.d.ts</code> に対しても型チェックを実施するため、コンパイル時間が増加します。 <code>skipLibCheck: true</code> を設定することで、型チェックの精度を犠牲にする代わりにコンパイル時間を削減できます。
<pre class="language-bash"><code class="language-bash"># skipLibkCheck: false
$ yarn tsc --extendedDiagnostics -p ./
Files: 88
Check time: 1.47s
Total time: 2.51s
✨ Done in 2.85s.

# skipLibCheck: true
$ yarn tsc --extendedDiagnostics -p ./
Files: 88
Check time: 0.18s
Total time: 1.17s
✨ Done in 1.49s.
</code></pre>
他のシナリオとしては、複数のパッケージが、それぞれが異なるバージョンの型定義ファイルに依存している（別々のパッケージ <code>@types/react@^16</code> と <code>@types/react@^17</code> に依存しているなど）場合に、同じ型定義ファイルが複数 node_modules にインストールされる場合があります。この時に <code>error TS2300: Duplicate Identifier</code> という型定義の重複エラーが発生してコンパイルに失敗します。
解決策としては、パッケージのバージョンを上げるなどして依存関係を整理して重複を無くす方法があります。しかし、それが難しい場合は <code>skipLibCheck: true</code> を指定することで型定義ファイルの型チェックをスキップすることで、エラーを回避することができます。
<h2 id="さいごに">さいごに</h2>
<code>skipLibCheck</code> は true or false のそれぞれにメリット・デメリットがあるため、プロジェクトで何を優先するかを決めて設定の有無を決めると良いでしょう。

ESLintは毎回プロジェクト開始の最初だけ設定して、その後あまり触ることが無く毎回なんとなくで設定して、新しく設定する時に設定項目を忘れてしまう事が多いので、各設定項目や導入プラグインの目的をちゃんと理解したいと思い、まとめました。

TypeScriptのskipLibCheckを理解する

<h2 id="はじめに">はじめに</h2>
TypeScriptをトランスパイルする手段として、主にtscとbabelという二つの選択肢があります。それぞれのツール役割について、どのような違いがあるかをまとめました。 
（webpackを利用する場合は、ts-loaderなどもありますが）
<h2 id="tsc">tsc</h2>
tscはTypeScriptの開発チームが提供しているTypeScriptのトランスパイラで、TypeScriptで書かれたソースコードをJavaScriptへとトランスパイルするツールです。tscは <code>tsconfig.json</code> の <code>target</code> オプションで古いJavaScriptへのトランスパイルをサポートしています。例えば、<code>&quot;target&quot;: &quot;es5&quot;</code> と指定することで、TypeScriptのコードをIE11などでも動くJavaScriptの構文にトランスパイルしてくれます。
しかし、ここで注意する点があります。tscのトランスパイル対象となるのは JavaScriptの構文だけ ということです。具体例として、次の <code>index.ts</code> をトランスパイルした <code>index.js</code> のコードを見てみます。
<pre class="language-typescript"><code class="language-typescript">// tsconfig.json
{
 "compilerOptions": {
 "target": "es5",
 "lib": [
 "ES2015"
 ]
 }
}

// index.ts
const fetchNumber = (): Promise&lt;number> => {
 return new Promise&lt;number>((resolve, reject) => {
 resolve(1);
 });
};

// index.js
var fetchNumber = function () {
 return new Promise(function (resolve, reject) {
 resolve(1);
 });
};
</code></pre>
<code>() =&gt; {}</code> のアロー関数はES2015で導入された構文であるため、IE11では利用できません。そこで、tscがアロー関数を <code>function() {}</code> のようにES5の形式に変換してくれています。ただ、<code>Promise</code> はそのままの形式で残っています。<code>Promise</code>もES2015から導入された仕組みのため、このままでは、IE11では動かすことができません。 
これは、先ほども述べたように tscのトランスパイルは JavaScriptの構文だけ を対象しており、Promiseなどの組み込みオブジェクトは構文でないため、tscのトランスパイル対象から外れてしまいます。
この問題を解決する方法として次に説明する Babel を利用します。
<h2 id="Babel">Babel</h2>
BabelはES2020などの最新のJavaScriptコードをIE11などのブラウザでも動作するJavaScriptコードに変換するトランパイラーです。また構文のトランスパイル以外にも、テストで利用する <code>test-id</code> や デバッグ目的の <code>console.log</code> をプロダクションビルドの時だけ削除するなどのトランスパイルを実行することができます。
<h3 id="Plugins と Presets">Plugins と Presets</h3>
Babelを利用する上で <code>Plugins</code> と <code>Presets</code> という二つの概念だけは把握しておく必要があります。
<code>Plugins</code>はBabelでどのようにコードを変換するかを定義したJSのプログラムです。 
例えば、<code>@babel/plugin-transform-arrow-functions</code> は ES2015から導入されたアロー関数 <code>() =&gt; {}</code> を <code>function() {}</code> というES5の形式に変化するためのプラグインです。Babelを利用する時は、複数のプラグインを組み合わせることで、目的に合わせてコードをトランスパイルしていきます。
実際にES2015の構文をES5にトランスパイルするには多くのプラグインを利用する必要があります。必要なプラグインを一つずつインストールして管理するのは大変です。一つのパッケージとして集約されていると、利用する際にパッケージをインストールするだけで良くなり非常に便利です。
この複数のプラグインを目的に応じてパッケージとして集約する仕組みが <code>Presets</code> です。ユーザーが独自のプリセットを定義することも、他の人が定義したプリセットをインストールして利用することもできます。頻繁に利用するプリセットとしては、Babel公式が提供している <code>@babel/preset-env</code> があります。これは、ES2015以降のJavaScriptの構文をES5にトランスパイルするプラグインを集約したプリセットです。集約されているプラグインは、<a href="https://github.com/babel/babel/blob/master/packages/babel-preset-env/src/available-plugins.js" target="_blank">babel/available-plugins.js at master · babel/babel</a> で確認できます。
<h3 id="TypeScriptのトランスパイル">TypeScriptのトランスパイル</h3>
実際に先ほどのTypeScriptのコードをBabelを利用してIE11でも動作するコードに変換してみます。
最初に必要なパッケージをインストールします。
<ul>
<li>@babel/cli: Babelのcliツール</li>
<li>@babel/core: Babelのコア機能</li>
<li>@babel/preset-env: JavaScriptの構文をトランスパイルする かつ PromiseなどのPolyfillを注入</li>
<li>@babel/preset-typescript: TypeScriptをトランスパイルする</li>
<li>core-js@3: PromiseなどのPolyfillを定義したモジュール</li>
</ul>
<pre class="language-bash"><code class="language-bash"># babelと関連するプリセットのインストール
$ yarn add -D @babel/cli @babel/core @babel/preset-env @babel/preset-typescript
$ yarn add core-js@3
</code></pre>
Babelの設定ファイルはこんな感じです。
<pre class="language-json"><code class="language-json">// babel.config.json
{
 "presets": [
 [
 "@babel/preset-typescript",
 "@babel/preset-env",
 {
 "targets": {
 "ie": "11"
 },
 "useBuiltIns": "usage"
 }
 ]
 ]
}
</code></pre>
TypeScript =&gt; @babel/preset-typescript =&gt; @babel/preset-env =&gt; JavaScript 
という流れでトランスパイルがされていきます。tscと異なる点は、<code>&quot;useBuiltIns&quot;: &quot;usage&quot;</code>を指定することで、<code>targets</code>オプションで 
指定しているブラウザでも動作させるために必要なPolyfillがBabelにより自動で注入されます。
実際に先ほどの <code>index.ts</code> に対してトランスパイルを実行して、出力されるJavaScriptを確認してみます。
<pre class="language-javascript"><code class="language-javascript">// src/index.js
"use strict";

require("core-js/modules/ES2015.promise.js");

require("core-js/modules/ES2015.object.to-string.js");

var fetchNumber = function fetchNumber() {
 return new Promise(function (resolve, reject) {
 resolve(1);
 });
};
</code></pre>
tscと比較して、<code>Promise</code>のPolyfillが別モジュールとして読み込まれています。このようにBabelを利用することで、より柔軟にトランスパイルすることができます。
ただし、ここでも注意が必要でPolyfillを <code>reuire</code> という CommonJS Module 形式で読み込んでいるため、このままではブラウザ上で実行することができません。そのため、このモジュール読み込みを解決するために、モジュールバンドラーのWebpackを利用します。
<h3 id="@babel/preset-typescriptの注意点">@babel/preset-typescriptの注意点</h3>
@babel/preset-typescriptの利用で知っておくべき注意点がいくつかあります。
<h4 id="型チェック">型チェック</h4>
ひとつは、型チェックが実行されないことです。BabelではTypeScriptから型を剥がして、JavaScriptにトランスパイルする作業だけを実行するため、仮に型の不整合が存在しても、トランスパイルが成功してしまいます。
<pre class="language-typescript"><code class="language-typescript">// src/index.ts
const n: number = "hello";
</code></pre>
上記のコードをtscとBabelで実行してみると、Babelでは型エラーが発生せずにトランスパイルが成功します。これでは、TypeScriptを使う一番の目的である型の恩恵が受けられません。
<pre class="language-bash"><code class="language-bash"># tscは型エラーでトランスパイルに失敗する
$ tsc src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.

1 const n: number = "test"
 ~
Found 1 error.

# Babelは型チェックされないのでトランスパイルに成功する
$ yarn babel src/index.ts
(#省略)
✨ Done in 0.54s.
</code></pre>
そのため、Babelでトランスパイルをする場合は、事前にtscで別途型チェックを実施する必要があります。
<pre class="language-bash"><code class="language-bash">$ tsc --noEmit src/index.ts &amp;&amp; babel src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.
</code></pre>
<h4 id="一部機能の非対応">一部機能の非対応</h4>
<code>const enums</code> や デコレーターなど一部のTypeScriptの機能を正常にトランスパイルできない問題があります。対応していないと絶対に困る問題ではないですが、プロジェクトによっては重要な問題となるので、これらの存在を認識していくことが重要です。 
詳細は <a href="https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/" target="_blank">Choosing between Babel and TypeScript</a> を参照してください。
<h2 id="おわりに">おわりに</h2>
Babelで 
今回は @babel/preset-typescript を利用したTypeScriptのトランスパイルを通して、tscとBabelの違いをまとめました。Babelで出力されたファイルはモジュール読み込みを含むため、webpackを利用してモジュール解決をする必要があります。しかし、webpackを利用する場合に、TypeScriptをトランスパイルする方法として <code>ts-loader</code> を使う方法もあります。別の機会にここら辺の話をまとめたいです。
<h2 id="参考">参考</h2>
<ul>
<li><a href="https://www.typescriptlang.org/tsconfig#target" target="_blank">TypeScript: TSConfig Reference - Docs on every TSConfig option</a></li>
<li><a href="https://babeljs.io/docs/en/babel-preset-env#usebuiltins" target="_blank">@babel/preset-env · Babel</a></li>
<li><a href="https://devblogs.microsoft.com/typescript/typescript-and-babel-7/" target="_blank">TypeScript and Babel 7 | TypeScript</a></li>
<li><a href="https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/" target="_blank">Choosing between Babel and TypeScript</a></li>
<li><a href="https://qiita.com/jagaapple/items/ce0da04be28c35dc7d4f#5-interfaces%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8Ftype-aliases%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B" target="_blank">TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita</a></li>
</ul>

TypeScriptをトランスパイルする際のtscとbabelそれぞれの役割をまとめました。

tscとBabel

1つのリポジトリ内でフロントエンドとサーバーのコードをディレクトリ分割の形式で管理していましたが、色々と辛くなってきたので、リファクタしてモノリポ化しました。 
その時に考慮した事をまとめています。
※ リファクタ後のリポジトリはプライベートリポジトリなので公開していません。
<h2 id="開発環境">開発環境</h2>
フロントエンドのフレームワークとしてNext.jsを利用しており、外部へのAPIリクエストのプロキシを目的としてBFFをNext.jsのカスタムサーバーとしてexpressを用いて実装しています。
<ul>
<li>BFF: TypeScript, Node.js, express（Next.jsのカスタムサーバー）</li>
<li>フロントエンド: TypeScript, Next.js</li>
</ul>
<h3 id="初期構成">初期構成</h3>
リファクタ前の構成は次のようになっており、ディレクトリ分割によりフロントとサーバーのコードを管理している状態でした。
<pre><code>.
├── .storybook
├── pages
├── public
├── src
│ ├── client
│ ├── common
│ ├── config
│ ├── server
│ └── types
├── stories
├── test
│ ├── src
│ │ ├── client
│ │ ├── common
│ │ └── server
│ └── tsconfig.json
├── next.config.js
├── nodemon.json
├── package.json
├── server.ts
├── tsconfig.json
├── tsconfig.common.json
└── tsconfig.server.json
</code></pre>
<h3 id="初期構成の問題">初期構成の問題</h3>
初期のディレクトリ構成ではルートに大量のファイルやディレクトリが存在していて、初見で見た時にどのファイルやディレクトリがフロントとサーバーのどちらに関係しているのか非常に分かり辛い状態でした。また <code>src</code> や <code>test</code> の中で <code>server</code> と <code>client</code> でディレクトリを分けていますが、フロントとサーバーではTypeScriptの設定が異なるため、tsconfigの設定も複雑化していました。 
※ 説明のために省略していますが、実際は他にもDockerのディレクトリなども存在します。
<h2 id="モノリポ化">モノリポ化</h2>
<h3 id="利用ツールの検討">利用ツールの検討</h3>
今回は yarn workspace のみを利用してモノリポ化を進めました。
モノリポ化で利用されるライブラリとしては <a href="https://github.com/lerna/lerna" target="_blank">lerna</a> が有名ですが、採用を見送りました。今回のケースでは yarn workspace のみで目的が達成できたのと、lerna が BabelなどのOSSプロジェクト（一般に公開する前提のプロジェクト）をモノリポ化する目的で作られているように見え、プライベートなリポジトリでは冗長かつ依存ツールを追加して管理コストが増える事は避けたかったからです。
フロントとサーバーをモノリポで管理するツールとして <a href="https://nx.dev/react" target="_blank">Nx</a> も検討しましたが、簡単に触った感じでは想像以上にフルスタックな印象を受け、Nx のディレクトリ構成に従う必要がありそうで、既存プロジェクトの移行コストが非常に高そうだったので見送りました。
参考として、 <a href="https://codewithhugo.com/yarn-workspaces-application-monorepo/" target="_blank">Yarn Workspaces: monorepo management without Lerna for applications and coding examples</a> とかの記事もありました。
<h3 id="TypeScript Project Reference">TypeScript Project Reference</h3>
モノリポ化にあたり、TypeScript の <a href="https://www.typescriptlang.org/docs/handbook/project-references.html" target="_blank">Project Reference</a> を新たに導入しました。これは、TS3.0 から追加された仕組みでTypeScriptのプロジェクトを独立して管理する事ができます。モノリポによりパッケージを分割するので、合わせてTypeScriptのビルドなどもパッケージ単位で分割したくて導入しました。
モノリポ環境では、@app/web =&gt; @app/server と依存している時に、@app/web を先にビルドすると、@app/server がビルドされておらずモジュール解決に失敗する問題が発生する可能性があります。Project Reference を導入すると、<code>tsc --build</code> と実行することで、@app/web をビルドする時に合わせて @app/server を必要に応じてビルドしてくれるので、依存関係の問題を解消する事もできます。
<h3 id="最終構成">最終構成</h3>
モノリポ化した後のディレクトリ構成は次のようになりました。フロントとサーバーがパッケージ単位で分割されて関連する設定ファイルやディレクトリもパッケージでまとめられたので、非常に見通しが良くなりました。
<pre><code>├── workspaces
| ├── common 複数のパッケージから共通で利用するパッケージ
| │ ├── src ソースコード置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── config 設定ファイルを保持するパッケージ
| │ ├── index.ts バレルファイル
| │ ├── firebase.ts 
| | ├── package.json
| | └── tsconfig.json TypeScriptの設定ファイル
| ├── server サーバー側のパッケージ
| │ ├── src ソースコード置き場
| │ ├── test テストコード置き場
| │ ├── types 型定義ファイル置き場
| | ├── package.json
| | └── tsconfig.json 
| ├── web
| | ├── .storybook Storybookの設定ファイル置き場
| | ├── public 画像などの公開ファイル置き場
| | ├── pages Next.jsのページコンポーネント置き場
| | ├── src
| | ├── stories Storybookのストーリーファイル置き場
| | ├── test テストコード置き場
| | ├── next.config.js Next.jsの設定ファイル
| | ├── nodemon.json 開発環境でのNext.jsのカスタムサーバー自動起動の設定
| | ├── package.json
| | ├── server.ts Next.jsのカスタムサーバー（実装はserverパッケージを参照）
| | ├── tsconfig.json
| | └── tsconfig.server.json
| └── tsconfig.json
└── pakcage.json
</code></pre>
<code>web</code> パッケージの package.json と tsconfig.json の一部です。
<pre class="language-json"><code class="language-json"># web/package.json

{
 "dependencies": {
 "@app/server": "*"
 }
}
</code></pre>
<pre class="language-json"><code class="language-json"># web/tsconfig.json

{
 "extends": "../tsconfig.json",
 "references": [
 { "path": "../server" }
 ]
}
</code></pre>

ディレクトリ分割でフロントエンドとサーバーのコードを管理していたリポジトリをリファクタしてモノリポ化した時のまとめ。

TypeScriptプロジェクトをモノリポ化した時のまとめ

CDK for Terraform のチュートリアルを TypeScript で試してみました。 
<a href="https://www.hashicorp.com/blog/cdk-for-terraform-enabling-python-and-typescript-support/" target="_blank">CDK for Terraform: Enabling Python &amp; TypeScript Support</a>
<h2 id="Terraformのインストール">Terraformのインストール</h2>
<a href="https://learn.hashicorp.com/terraform/getting-started/install.html" target="_blank">Install Terraform | Terraform - HashiCorp Learn</a>
<pre class="language-shell"><code class="language-shell">$ brew install terraform
</code></pre>
<h2 id="CDK for terraform のインストール">CDK for terraform のインストール</h2>
<pre class="language-shell"><code class="language-shell">$ yarn global add cdktf-cli
</code></pre>
<h2 id="AWSでVPCを構築するチュートリアル">AWSでVPCを構築するチュートリアル</h2>
<h3 id="プロジェクトの作成">プロジェクトの作成</h3>
Terraform Cloud でリモートステートを管理するか聞かれるので &quot;no&quot; とする。
<pre class="language-shell"><code class="language-shell">$ mkdir vpc-example
$ cd vpc-example
$ cdktf init --template=typescript
...
Do you want to continue with Terraform Cloud remote state management (yes/no)? no
Project Name: (default: 'vpc-example')
Project Description: (default: 'A simple getting started project for cdktf.')
</code></pre>
<h3 id="実装">実装</h3>
TerraformのHCLと比較すると、型のおかげで必須オプションの漏れなどが、リアルタイムで分かるのは良いですね。
<pre class="language-typescript"><code class="language-typescript">import { Construct } from 'constructs';
import { App, TerraformStack, Token } from 'cdktf';
import { Vpc } from './.gen/providers/aws/vpc';
import { Subnet } from './.gen/providers/aws/subnet';
import { AwsProvider } from './.gen/providers/aws'

class MyStack extends TerraformStack {
 constructor(scope: Construct, name: string) {
 super(scope, name);

 new AwsProvider(this, 'aws', {
 region: 'ap-northeast-1'
 });

 const vpc = new Vpc(this, 'my-vpc', {
 cidrBlock: '10.0.0.0/16'
 });
 new Subnet(this, 'my-subnet', {
 vpcId: Token.asString(vpc.id),
 cidrBlock: '10.0.0.0/24'
 });
 }
}

const app = new App();
new MyStack(app, 'vpc-example');
app.synth();
</code></pre>
<h3 id="TerraformのJSONファイルを生成">TerraformのJSONファイルを生成</h3>
TypeScriptのコードからTerraformのJSON形式の設定ファイルをに生成します。ファイルは<code>cdk.tf</code>ディレクトリに出力されます。
<pre class="language-shell"><code class="language-shell">$ cdktf synth
Generated Terraform code in the output directory: cdktf.out

$ tree cdktf.out
cdktf.out
└── cdk.tf.json
</code></pre>
<h3 id="Terraformを実行">Terraformを実行</h3>
生成された設定ファイルを元に terraform を実行することで、AWSにVPCを構築できます。 
設定がまだの場合は事前に <code>aws configure</code> で設定を完了させておく必要があります。
AWSコンソールのVPCを確認すれば、新しくリソースが作成されている事が確認できます。
<pre class="language-shell"><code class="language-shell">$ cd cdktf.out
$ terraform init
$ terraform plan
...
# 追加されるVPCの情報が表示される

$ terraform apply
aws_vpc.vpcexample_myvpc_80A1790F: Creating...
aws_vpc.vpcexample_myvpc_80A1790F: Still creating... [10s elapsed]
aws_vpc.vpcexample_myvpc_80A1790F: Creation complete after 10s [id=vpc-09aeca6257ae5fe31]
aws_subnet.vpcexample_mysubnet_3769B309: Creating...
aws_subnet.vpcexample_mysubnet_3769B309: Creation complete after 3s [id=subnet-0264b990708ed4f69]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
</code></pre>
<h3 id="リソースの削除">リソースの削除</h3>
最後に今回のチュートリアルで作成したVPCを削除しておきます。
<pre><code>$ terraform destroy
</code></pre>

CDK for Terraform でVPCを構築するチュートリアルです

CDK for Terraform でVPCを構築するチュートリアル

<h2 id="インストール">インストール</h2>
<a href="https://github.com/denoland/deno" target="_blank">denoland/deno: A secure JavaScript and TypeScript runtime</a>
<pre class="language-shell"><code class="language-shell">$ curl -fsSL https://deno.land/x/install/install.sh | sh
$ vi ~/.zshrc
# Denoのパス設定
export DENO_INSTALL="/Users/t-yng/.local"
export PATH="$DENO_INSTALL/bin:$PATH"

$ source ~/.zshrc
</code></pre>
インストール直後はパスが通っていない状態なので ~/.zshrc にDenoのパス設定を追加して再読み込みします。 
※ 個人の環境に合わせて適宜読み替えてください
HomeblewやCargoを利用してもインストールできます。 
詳細は <a href="https://deno.land/" target="_blank">https://deno.land/</a> を確認してください。
<h2 id="VsCodeの拡張">VsCodeの拡張</h2>
今の状態でVSCodeでコードを書くとTypeScriptとして認識されるので、Denoの構文でエラーが発生します。 
そこで <a href="https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno" target="_blank">Deno - Visual Studio Marketplace</a> をインストールしておきます。
デフォルトでは設定が false になっているので .vscode/setting.json で拡張を有効化します。 
自分は Node.js 環境で TypeScript を書く場合に競合する事を避けるために、プロジェクト単位で有効化しています。
<pre class="language-json"><code class="language-json">{
 "deno.enable": true
}
</code></pre>
<h2 id="Hello World を表示する">Hello World を表示する</h2>
最初に「Hello World」を表示するサンプルコードを実装してみます。
<pre class="language-shell"><code class="language-shell">$ mkdir deno-sample
$ cd deno-sample
$ touch server.ts
</code></pre>
<h3 id="server.ts">server.ts</h3>
deno-sample/server.ts に次のサンプルコードを記述します。
<pre class="language-typescript"><code class="language-typescript">import { serve } from "https://deno.land/std@v0.39.0/http/server.ts";

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000/");

for await (const req of s) {
 req.respond({ body: "Hello World\n" });
}
</code></pre>
最初のimport文はモジュール読み込みです。 
Denoは npm を利用せずにURLやファイルパスでモジュールを読み込む仕組みになっており、サンプルコードでは deno.land にホスティングされた標準APIのモジュールを読み込んでいます。
次に <code>serve({port: 8000})</code> でサーバーインスタンスを生成しています。
ここで生成されるサーバーインスタンスはPromiseのイテレーターとなっているので、 <code>for await</code> でループ処理にてリクエストのインスタンスを取得して、 Hello World の文字列をレスポンスとして返しています。
<h3 id="実行">実行</h3>
エラーが発生しました。
<pre class="language-shell"><code class="language-shell">$ deno server.ts

Compile file:///Users/xxxxxx/workspace/deno/deno-sample/server.ts
error: Uncaught PermissionDenied: network access to "127.0.0.1:8000", run again with the --allow-net flag
</code></pre>
Denoではネットワークアクセスやファイルアクセスには許可が必要なため、今回はネットワークアクセスを許可するために <code>--allow-net</code> フラグを指定します。
<pre><code>$ deno --allow-net server.ts
access to http://localhost:8000/
</code></pre>
今度は成功しました。 
この状態で http://localhost:8000/ にアクセスすれば、「Hello World」がブラウザに表示されます。🎉
<h2 id="HTMLを返す">HTMLを返す</h2>
次にHTMLを返すWebサーバーを実装してみます。
<h3 id="ディレクトリ構造">ディレクトリ構造</h3>
public/index.html は適当に作成してください。
<pre><code>.
├── public
│   └── index.html
└── server.ts
</code></pre>
<h3 id="server.ts">server.ts</h3>
fs モジュールの <code>readFileStr</code> でHTMLファイルの文字列を読み込みをしています。
正しく実装するなら、<a href="https://deno.land/std/manual.md#file-server" target="_blank">File Server</a>として実装した方が良さそうですが、ファイル読み込みをを試してみたかったので、この書き方をしています。
<pre class="language-typescript"><code class="language-typescript">import { serve } from "https://deno.land/std/http/server.ts";
import { readFileStr } from "https://deno.land/std/fs/mod.ts";

// HTMLファイルを読み込んで文字列を取得
const html = await readFileStr("./public/index.html", {
 encoding: "utf8",
}).catch((error) => {
 console.log(error);
 return "読み込みに失敗したよ";
});

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000");
for await (const req of s) {
 req.respond({ body: html }); // HTML文字列をレスポンスBodyにセット
}
</code></pre>
<h3 id="実行">実行</h3>
ファイル読み込みをしているので <code>--allow-read</code> フラグを新たに指定しています。
<pre class="language-shell"><code class="language-shell">$ deno --allow-net --allow-read server.ts
access to http://localhost:8000/
</code></pre>
<h2 id="パッケージ管理">パッケージ管理</h2>
<h3 id="問題">問題</h3>
現状では npm のようなパッケージ管理ツールがなく、ソース単位で外部モジュールの読み込みを書いている状態です。 
依存している外部ライブラリを把握するためには、ソースコードを全て見る必要があり管理が困難になってしまいます。
<h3 id="deps.ts">deps.ts</h3>
deps.ts ファイルを新しく作り、モジュール読み込みの記述をまとめることで簡易的なパッケージ管理が実現できます。 
deps.ts はマニュアルで紹介されいているファイル名で名前は何でもOKです。 
ライブラリを見ていると、deps.ts か package.ts をファイル名として利用しているパターンが多かったです。
先ほどのHTMLを返すサンプルコードの一部を deps.ts を利用して書き直してみるとこんな感じです。
deps.ts
<pre class="language-typescript"><code class="language-typescript">export { serve } from "https://deno.land/std/http/server.ts";
export { readFileStr } from "https://deno.land/std/fs/mod.ts";
</code></pre>
server.ts
<pre class="language-typescript"><code class="language-typescript">import { serve, readFileStr } from "./deps.ts";

// 後は同じ
...
</code></pre>
<h2 id="ドキュメント">ドキュメント</h2>
<ul>
<li><a href="https://deno.land/" target="_blank">Dono 公式ドキュメント</a></li>
<li><a href="https://deno.land/typedoc/" target="_blank">API Reference</a></li>
</ul>

Denoを触ってみよう

とあるフロントエンドエンジニアのブログ

typescriptの記事一覧