
tsconfig.json には [skipLibCheck](https://www.typescriptlang.org/ja/tsconfig#skipLibCheck) という設定オプションがあります。  
このオプションの挙動やどんな時に設定するかについてまとめました。

## skipLibCheckの挙動
このオプションのデフォルト値は false で true を設定することで `*.d.ts` ファイルに対する型チェックをスキップすることができます。

次のようなサーバーのコードを考えてみます。

```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");
});
```

tsconfig.json では `skipLibCheck` は定義しておらず、デフォルトの false が設定されている状態です。

```json
{
    "compilerOptions": {
        "esModuleInterop": true,
        "typeRoots": [
            "node_modules/@types",
            "types"
        ]
    }
}
```

`req.tokens` は次のような型定義ファイルを作成して、 `express.Request` の型定義を拡張して新たにプロパティを定義しています。この時、 `tokens: Array` とジェネリクスを指定すべき箇所を誤って指定しているため、型定義エラーが発生しています。

```typescript
// types/express/index.d.ts
/// <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<T>
        // Generic type 'Array<T>' requires 1 type argument(s).ts(2314)
        tokens: Array;
    }
}
```

この状態で、 tsconfig.json にて `skipLibCheck: true` を設定します。

```json
{
    "compilerOptions": {
        "skipLibCheck": true,
        // (省略)
    }
}
```

`*.d.ts` ファイルに対する型チェックがスキップされるのでエラーが消え、正しくない型定義ファイルが存在してもコンパイルエラーが出なくなってしまいました。

```typescript
declare namespace Express {
    export interface Request {
        tokens: Array;
    }
}
```

この状態では `req.tokens` は `any` として解釈されます。

```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);
    }
});
```

## skipLibCheckのメリット
挙動を見る限りでは `skipLibCheck: true` を設定することで、型チェックの精度が下がるデメリットがありましたが `skipLibCheck: true` を設定するメリットは何なのでしょうか？

アプリケーションが中規模、大規模になり依存するパッケージが増えた時に、それに比例して型定義ファイルが増えていきます。 `tsc` のデフォルトの挙動では、TypeScriptをコンパイルするときに `@types/express` などのライブラリの `*.d.ts` に対しても型チェックを実施するため、コンパイル時間が増加します。 `skipLibCheck: true` を設定することで、型チェックの精度を犠牲にする代わりにコンパイル時間を削減できます。

```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.
```

他のシナリオとしては、複数のパッケージが、それぞれが異なるバージョンの型定義ファイルに依存している（別々のパッケージ `@types/react@^16` と `@types/react@^17` に依存しているなど）場合に、同じ型定義ファイルが複数 node_modules にインストールされる場合があります。この時に `error TS2300: Duplicate Identifier` という型定義の重複エラーが発生してコンパイルに失敗します。  

解決策としては、パッケージのバージョンを上げるなどして依存関係を整理して重複を無くす方法があります。しかし、それが難しい場合は  `skipLibCheck: true` を指定することで型定義ファイルの型チェックをスキップすることで、エラーを回避することができます。

## さいごに
`skipLibCheck` は true or false のそれぞれにメリット・デメリットがあるため、プロジェクトで何を優先するかを決めて設定の有無を決めると良いでしょう。


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

TypeScriptのskipLibCheckを理解する


## はじめに
TypeScriptをトランスパイルする手段として、主にtscとbabelという二つの選択肢があります。それぞれのツール役割について、どのような違いがあるかをまとめました。  
（webpackを利用する場合は、ts-loaderなどもありますが）

## tsc
tscはTypeScriptの開発チームが提供しているTypeScriptのトランスパイラで、TypeScriptで書かれたソースコードをJavaScriptへとトランスパイルするツールです。tscは `tsconfig.json` の `target` オプションで古いJavaScriptへのトランスパイルをサポートしています。例えば、`"target": "es5"` と指定することで、TypeScriptのコードをIE11などでも動くJavaScriptの構文にトランスパイルしてくれます。

しかし、ここで注意する点があります。tscのトランスパイル対象となるのは **JavaScriptの構文だけ** ということです。具体例として、次の `index.ts` をトランスパイルした `index.js` のコードを見てみます。  

```typescript
// tsconfig.json
{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "ES2015"
    ]
  }
}

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

// index.js
var fetchNumber = function () {
    return new Promise(function (resolve, reject) {
        resolve(1);
    });
};
```

`() => {}` のアロー関数はES2015で導入された構文であるため、IE11では利用できません。そこで、tscがアロー関数を `function() {}` のようにES5の形式に変換してくれています。ただ、`Promise` はそのままの形式で残っています。`Promise`もES2015から導入された仕組みのため、このままでは、IE11では動かすことができません。
これは、先ほども述べたように tscのトランスパイルは **JavaScriptの構文だけ** を対象しており、Promiseなどの組み込みオブジェクトは構文でないため、tscのトランスパイル対象から外れてしまいます。

この問題を解決する方法として次に説明する Babel を利用します。

## Babel
BabelはES2020などの最新のJavaScriptコードをIE11などのブラウザでも動作するJavaScriptコードに変換するトランパイラーです。また構文のトランスパイル以外にも、テストで利用する `test-id` や デバッグ目的の `console.log` をプロダクションビルドの時だけ削除するなどのトランスパイルを実行することができます。

### Plugins と Presets
Babelを利用する上で `Plugins` と `Presets` という二つの概念だけは把握しておく必要があります。  

`Plugins`はBabelでどのようにコードを変換するかを定義したJSのプログラムです。  
例えば、`@babel/plugin-transform-arrow-functions` は ES2015から導入されたアロー関数 `() => {}` を `function() {}` というES5の形式に変化するためのプラグインです。Babelを利用する時は、複数のプラグインを組み合わせることで、目的に合わせてコードをトランスパイルしていきます。

実際にES2015の構文をES5にトランスパイルするには多くのプラグインを利用する必要があります。必要なプラグインを一つずつインストールして管理するのは大変です。一つのパッケージとして集約されていると、利用する際にパッケージをインストールするだけで良くなり非常に便利です。  

この複数のプラグインを目的に応じてパッケージとして集約する仕組みが `Presets` です。ユーザーが独自のプリセットを定義することも、他の人が定義したプリセットをインストールして利用することもできます。頻繁に利用するプリセットとしては、Babel公式が提供している `@babel/preset-env` があります。これは、ES2015以降のJavaScriptの構文をES5にトランスパイルするプラグインを集約したプリセットです。集約されているプラグインは、[babel/available\-plugins\.js at master · babel/babel](https://github.com/babel/babel/blob/master/packages/babel-preset-env/src/available-plugins.js) で確認できます。

### TypeScriptのトランスパイル
実際に先ほどのTypeScriptのコードをBabelを利用してIE11でも動作するコードに変換してみます。  

最初に必要なパッケージをインストールします。

- @babel/cli: Babelのcliツール
- @babel/core: Babelのコア機能
- @babel/preset-env: JavaScriptの構文をトランスパイルする かつ PromiseなどのPolyfillを注入
- @babel/preset-typescript: TypeScriptをトランスパイルする
- core-js@3: PromiseなどのPolyfillを定義したモジュール

```bash
# babelと関連するプリセットのインストール
$ yarn add -D @babel/cli @babel/core @babel/preset-env @babel/preset-typescript
$ yarn add core-js@3
```

Babelの設定ファイルはこんな感じです。

```json
// babel.config.json
{
  "presets": [
    [
      "@babel/preset-typescript",
      "@babel/preset-env",
      {
        "targets": {
          "ie": "11"
        },
        "useBuiltIns": "usage"
      }
    ]
  ]
}
```

TypeScript => @babel/preset-typescript => @babel/preset-env => JavaScript  
という流れでトランスパイルがされていきます。tscと異なる点は、`"useBuiltIns": "usage"`を指定することで、`targets`オプションで
指定しているブラウザでも動作させるために必要なPolyfillがBabelにより自動で注入されます。

実際に先ほどの `index.ts` に対してトランスパイルを実行して、出力されるJavaScriptを確認してみます。

```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);
  });
};
```

tscと比較して、`Promise`のPolyfillが別モジュールとして読み込まれています。このようにBabelを利用することで、より柔軟にトランスパイルすることができます。

ただし、ここでも注意が必要でPolyfillを `reuire` という CommonJS Module 形式で読み込んでいるため、このままではブラウザ上で実行することができません。そのため、このモジュール読み込みを解決するために、モジュールバンドラーのWebpackを利用します。


### @babel/preset-typescriptの注意点
@babel/preset-typescriptの利用で知っておくべき注意点がいくつかあります。

#### 型チェック
ひとつは、型チェックが実行されないことです。BabelではTypeScriptから型を剥がして、JavaScriptにトランスパイルする作業だけを実行するため、仮に型の不整合が存在しても、トランスパイルが成功してしまいます。

```typescript
// src/index.ts
const n: number = "hello";
```

上記のコードをtscとBabelで実行してみると、Babelでは型エラーが発生せずにトランスパイルが成功します。これでは、TypeScriptを使う一番の目的である型の恩恵が受けられません。

```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.
```

そのため、Babelでトランスパイルをする場合は、事前にtscで別途型チェックを実施する必要があります。

```bash
$ tsc --noEmit src/index.ts && babel src/index.ts
src/test.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.
```

#### 一部機能の非対応
`const enums` や デコレーターなど一部のTypeScriptの機能を正常にトランスパイルできない問題があります。対応していないと絶対に困る問題ではないですが、プロジェクトによっては重要な問題となるので、これらの存在を認識していくことが重要です。  
詳細は [Choosing between Babel and TypeScript](https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/) を参照してください。

## おわりに
Babelで
今回は @babel/preset-typescript を利用したTypeScriptのトランスパイルを通して、tscとBabelの違いをまとめました。Babelで出力されたファイルはモジュール読み込みを含むため、webpackを利用してモジュール解決をする必要があります。しかし、webpackを利用する場合に、TypeScriptをトランスパイルする方法として `ts-loader` を使う方法もあります。別の機会にここら辺の話をまとめたいです。

## 参考
- [TypeScript: TSConfig Reference \- Docs on every TSConfig option](https://www.typescriptlang.org/tsconfig#target)
- [@babel/preset\-env · Babel](https://babeljs.io/docs/en/babel-preset-env#usebuiltins)
- [TypeScript and Babel 7 \| TypeScript](https://devblogs.microsoft.com/typescript/typescript-and-babel-7/)
- [Choosing between Babel and TypeScript](https://blog.logrocket.com/choosing-between-babel-and-typescript-4ed1ad563e41/)
- [TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 \- Qiita](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)


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

tscとBabel


1つのリポジトリ内でフロントエンドとサーバーのコードをディレクトリ分割の形式で管理していましたが、色々と辛くなってきたので、リファクタしてモノリポ化しました。  
その時に考慮した事をまとめています。

※ リファクタ後のリポジトリはプライベートリポジトリなので公開していません。

## 開発環境
フロントエンドのフレームワークとしてNext.jsを利用しており、外部へのAPIリクエストのプロキシを目的としてBFFをNext.jsのカスタムサーバーとしてexpressを用いて実装しています。

* BFF: TypeScript, Node.js, express（Next.jsのカスタムサーバー）
* フロントエンド: TypeScript, Next.js

### 初期構成
リファクタ前の構成は次のようになっており、ディレクトリ分割によりフロントとサーバーのコードを管理している状態でした。

```
.
├── .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
```

### 初期構成の問題
初期のディレクトリ構成ではルートに大量のファイルやディレクトリが存在していて、初見で見た時にどのファイルやディレクトリがフロントとサーバーのどちらに関係しているのか非常に分かり辛い状態でした。また `src` や `test` の中で `server` と `client` でディレクトリを分けていますが、フロントとサーバーではTypeScriptの設定が異なるため、tsconfigの設定も複雑化していました。  
※ 説明のために省略していますが、実際は他にもDockerのディレクトリなども存在します。

## モノリポ化

### 利用ツールの検討
今回は yarn workspace のみを利用してモノリポ化を進めました。

モノリポ化で利用されるライブラリとしては [lerna](https://github.com/lerna/lerna) が有名ですが、採用を見送りました。今回のケースでは yarn workspace のみで目的が達成できたのと、lerna が BabelなどのOSSプロジェクト（一般に公開する前提のプロジェクト）をモノリポ化する目的で作られているように見え、プライベートなリポジトリでは冗長かつ依存ツールを追加して管理コストが増える事は避けたかったからです。

フロントとサーバーをモノリポで管理するツールとして [Nx](https://nx.dev/react) も検討しましたが、簡単に触った感じでは想像以上にフルスタックな印象を受け、Nx のディレクトリ構成に従う必要がありそうで、既存プロジェクトの移行コストが非常に高そうだったので見送りました。

参考として、 [Yarn Workspaces: monorepo management without Lerna for applications and coding examples](https://codewithhugo.com/yarn-workspaces-application-monorepo/) とかの記事もありました。

### TypeScript Project Reference
モノリポ化にあたり、TypeScript の [Project Reference](https://www.typescriptlang.org/docs/handbook/project-references.html) を新たに導入しました。これは、TS3.0 から追加された仕組みでTypeScriptのプロジェクトを独立して管理する事ができます。モノリポによりパッケージを分割するので、合わせてTypeScriptのビルドなどもパッケージ単位で分割したくて導入しました。

モノリポ環境では、@app/web => @app/server と依存している時に、@app/web を先にビルドすると、@app/server がビルドされておらずモジュール解決に失敗する問題が発生する可能性があります。Project Reference を導入すると、`tsc --build` と実行することで、@app/web をビルドする時に合わせて @app/server を必要に応じてビルドしてくれるので、依存関係の問題を解消する事もできます。

### 最終構成

モノリポ化した後のディレクトリ構成は次のようになりました。フロントとサーバーがパッケージ単位で分割されて関連する設定ファイルやディレクトリもパッケージでまとめられたので、非常に見通しが良くなりました。

```
├── 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
```

`web` パッケージの package.json と tsconfig.json の一部です。

```json
# web/package.json

{
    "dependencies": {
        "@app/server": "*"
    }
}
```

```json
# web/tsconfig.json

{
    "extends": "../tsconfig.json",
    "references": [
        { "path": "../server" }
    ]
}
```


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

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


CDK for Terraform のチュートリアルを TypeScript で試してみました。  
[CDK for Terraform: Enabling Python & TypeScript Support](https://www.hashicorp.com/blog/cdk-for-terraform-enabling-python-and-typescript-support/)

## Terraformのインストール
[Install Terraform \| Terraform - HashiCorp Learn](https://learn.hashicorp.com/terraform/getting-started/install.html)

```shell
$ brew install terraform
```

## CDK for terraform のインストール

```shell
$ yarn global add cdktf-cli
```

## AWSでVPCを構築するチュートリアル

### プロジェクトの作成
Terraform Cloud でリモートステートを管理するか聞かれるので "no" とする。

```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.')
```

### 実装
TerraformのHCLと比較すると、型のおかげで必須オプションの漏れなどが、リアルタイムで分かるのは良いですね。

```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();
```

### TerraformのJSONファイルを生成
TypeScriptのコードからTerraformのJSON形式の設定ファイルをに生成します。ファイルは`cdk.tf`ディレクトリに出力されます。

```shell
$ cdktf synth
Generated Terraform code in the output directory: cdktf.out

$ tree cdktf.out
cdktf.out
└── cdk.tf.json
```

### Terraformを実行
生成された設定ファイルを元に terraform を実行することで、AWSにVPCを構築できます。  
設定がまだの場合は事前に `aws configure` で設定を完了させておく必要があります。

AWSコンソールのVPCを確認すれば、新しくリソースが作成されている事が確認できます。

```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.
```

### リソースの削除
最後に今回のチュートリアルで作成したVPCを削除しておきます。

```
$ terraform destroy
```

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

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


## インストール
[denoland/deno: A secure JavaScript and TypeScript runtime](https://github.com/denoland/deno)

```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
```

インストール直後はパスが通っていない状態なので ~/.zshrc にDenoのパス設定を追加して再読み込みします。  
※ 個人の環境に合わせて適宜読み替えてください

HomeblewやCargoを利用してもインストールできます。  
詳細は [https://deno.land/](https://deno.land/) を確認してください。

## VsCodeの拡張

今の状態でVSCodeでコードを書くとTypeScriptとして認識されるので、Denoの構文でエラーが発生します。  
そこで [Deno - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno) をインストールしておきます。

デフォルトでは設定が false になっているので .vscode/setting.json で拡張を有効化します。  
自分は Node.js 環境で TypeScript を書く場合に競合する事を避けるために、プロジェクト単位で有効化しています。

```json
{
  "deno.enable": true
}
```

## Hello World を表示する
最初に「Hello World」を表示するサンプルコードを実装してみます。

```shell
$ mkdir deno-sample
$ cd deno-sample
$ touch server.ts
```

### server.ts
deno-sample/server.ts に次のサンプルコードを記述します。

```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" });
}
```

最初のimport文はモジュール読み込みです。  
Denoは npm を利用せずにURLやファイルパスでモジュールを読み込む仕組みになっており、サンプルコードでは deno.land にホスティングされた標準APIのモジュールを読み込んでいます。

次に `serve({port: 8000})` でサーバーインスタンスを生成しています。

ここで生成されるサーバーインスタンスはPromiseのイテレーターとなっているので、 `for await` でループ処理にてリクエストのインスタンスを取得して、 Hello World の文字列をレスポンスとして返しています。

### 実行
エラーが発生しました。

```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
```

Denoではネットワークアクセスやファイルアクセスには許可が必要なため、今回はネットワークアクセスを許可するために `--allow-net` フラグを指定します。

```
$ deno --allow-net server.ts
access to http://localhost:8000/
```

今度は成功しました。
この状態で http://localhost:8000/ にアクセスすれば、「Hello World」がブラウザに表示されます。🎉

## HTMLを返す
次にHTMLを返すWebサーバーを実装してみます。

### ディレクトリ構造
public/index.html は適当に作成してください。

```
.
├── public
│   └── index.html
└── server.ts
```

### server.ts

fs モジュールの `readFileStr` でHTMLファイルの文字列を読み込みをしています。

正しく実装するなら、[File Server](https://deno.land/std/manual.md#file-server)として実装した方が良さそうですが、ファイル読み込みをを試してみたかったので、この書き方をしています。

```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にセット
}
```

### 実行
ファイル読み込みをしているので `--allow-read` フラグを新たに指定しています。

```shell
$ deno --allow-net --allow-read server.ts
access to http://localhost:8000/
```

## パッケージ管理

### 問題
現状では npm のようなパッケージ管理ツールがなく、ソース単位で外部モジュールの読み込みを書いている状態です。  
依存している外部ライブラリを把握するためには、ソースコードを全て見る必要があり管理が困難になってしまいます。

### deps.ts
deps.ts ファイルを新しく作り、モジュール読み込みの記述をまとめることで簡易的なパッケージ管理が実現できます。  
deps.ts はマニュアルで紹介されいているファイル名で名前は何でもOKです。  
ライブラリを見ていると、deps.ts か package.ts をファイル名として利用しているパターンが多かったです。

先ほどのHTMLを返すサンプルコードの一部を deps.ts を利用して書き直してみるとこんな感じです。

deps.ts
```typescript
export { serve } from "https://deno.land/std/http/server.ts";
export { readFileStr } from "https://deno.land/std/fs/mod.ts";
```

server.ts
```typescript
import { serve, readFileStr } from "./deps.ts";

// 後は同じ
...
```

## ドキュメント

* [Dono 公式ドキュメント](https://deno.land/)
* [API Reference](https://deno.land/typedoc/)


Denoを触ってみよう

神奈川の田舎で働いてるフロントエンドエンジニアのブログ