# 結論

Issueで提案されてる実行時検証が良い


# 余計なfieldを含んでいても型エラーにならない問題

Typescript と Hono と openapi-zod を使っているときの話です。
余計なfieldを含んでいても型エラーにならない問題がります。余計なkeyと言ってもいいかも。

以下のissueで報告されています。

https://github.com/honojs/middleware/issues/913

https://github.com/honojs/middleware/issues/181


例えばopenapi-zodで以下のschemaを定義しているとします。idだけを持つレスポンスを返すとします。

```ts
const UserResponseSchema = z
  .object({
    id: z.string(),
  })
  .openapi("UserResponseSchema")
```

これを使ったAPIのエンドポイントを追加するとき、余計なfieldを含めてみましょう。今回はpasswordを追加しています。Hono openapi-zodのレスポンスの型はゆるくて型エラーになりません。

```ts
app.openapi(
  createRoute({
    method: "get",
    path: "/users/1",
    responses: {
      200: {
        content: {
          "application/json": {
            schema: UserResponseSchema,
          },
        },
        description: "return a user",
      },
    },
  }),
  async (c) => {
    const responseUser = {
      id: "1",
      password: "xxxx",
    }
    return c.json(responseUser, 200)
  },
)

```

これでは間違ったfieldが含まれたときに気付けなくて困ります。
せっかくTypescriptを使っているので型エラーで検知したいです。

ちなみにschemaに定義しているfieldが足りないときは型エラーになります。


# issueで提案されてる方法

zodでパースして実行時に余計なfieldが含まれているときエラーにするコードが提案されています。

```ts
import type { Context } from "hono";
import type { ContentfulStatusCode } from "hono/utils/http-status";
import type { z, ZodSchema } from "zod";

export function strictJSONResponse<
  C extends Context,
  S extends ZodSchema,
  D extends Parameters<Context["json"]>[0] & z.infer<S>,
  U extends ContentfulStatusCode
>(c: C, schema: S, data: D, statusCode?: U) {
  const validatedResponse = schema.safeParse(data);

  if (!validatedResponse.success) {
    return c.json(
      {
        message: "Strict response validation failed",
      },
      500
    );
  }

  return c.json(validatedResponse.data, statusCode);
}
```

引用: https://github.com/honojs/middleware/issues/913#issuecomment-2889258966

openapi-zodのschemaは`.strict()`してる必要があります。

使い方はこんな感じかな

```ts
return strictJSONResponse(
  c,
  z
    .object({
      id: z.string(),
    })
    .strict(),
  { id: "1" },
  200,
)
```



# 試したけどだめだった方法

レスポンスのschemaから型を作成し、オブジェクトを検証する。
以下のようなイメージです。

```ts
import { createRoute, OpenAPIHono } from "@hono/zod-openapi"
import { z } from "@hono/zod-openapi"

const app= new OpenAPIHono()

const UserResponseSchema = z
  .object({
    id: z.string(),
  })
  .openapi("UserResponseSchema")

app.openapi(
  createRoute({
    method: "get",
    path: "/users/1",
    responses: {
      200: {
        content: {
          "application/json": {
            schema: UserResponseSchema,
          },
        },
        description: "return a user",
      },
    },
  }),
  async (c) => {
    const responseUser: z.infer<typeof UserResponseSchema> = {
      id: "1",
      password: "xxxx",
    }
    return c.json(responseUser, 200)
  },
)

```

`z.infer<typeof UserResponseSchema>`という型で検証するようにしました。
これによって`password`の部分で型エラーが出ます。

```ts
 error TS2353: Object literal may only specify known properties, and 'password' does not exist in type '{ id: string; }'.

80       password: "xxxx",
         ~~~~~~~~
```

しかし、Typescriptは子要素のfieldで型エラーが出ないケースが存在し、実用的でありませんでした。

```ts
const a = { a: 0, b: { a: 0, b: 1 } }

const c = (d: { a: number; b: { a: number } }) => {}

c(a) // 型エラーにならない

c({ a: 0, b: { a: 0, b: 1 } }) // 型エラーになる
```

詳しくはこの辺の記事に書かれている

https://numb86-tech.hatenablog.com/entry/2020/02/02/100816

入れ子になったfieldsやmapメソッドや関数を使って代入したときに型エラーが出なくなってしまう。


Hono + zod-openapi でレスポンスに余計なfieldを含めても型エラーにならない問題

Cloudflare d1 + Prisma を以前試していました。

Rails の Active record に脳髄を侵されている自分にとって Prisma の使い心地は非常によかったのですが、D1と組み合わせるにあたって相性が悪かったので Drizzle に移行しました。

https://noh.ink/articles/cdnuIsO3dLOpIHcFkO2d


# 不便だったことや機能不足

## D1 の batch メソッドと組み合わせられない。

これがほぼすべての理由です。

D1がトランザクションに対応してない事自体は知っていました。
分散型のDBとトランザクショを組み合わせるのは難しいみたいで、現時点で実装予定も無いそうです。

https://github.com/cloudflare/workers-sdk/issues/2733

その代わりに提供されているのが、Batchメソッドです。これは複数のSQLを単一の呼び出しに送信するバッチ処理を行うものです。バッチ処理はトランザクションとして扱われ、途中で失敗した場合はその文にエラーが返され、全体が中止またはロールバックされます。
そこまで複雑なアプリでなければ、これである程度乗り切れそうな気はします。

https://developers.cloudflare.com/d1/worker-api/d1-database/#batch

Prismaを使い始めて気づいたのですが、Prismaからこのbatchメソッドを使う方法がありません。Activerecordのto_sqlメソッドのようなものがあるだろうと思っていたのですが、ありませんでした。

当時、issueやドキュメント、ソースコード、公式discordまで見ましたがありません。batchメソッドを使うときは生のSQLを書く必要があります。
一部とはいえ、生のSQLを書かないといけないのは明確にデメリットです。

テーブル設計で回避することも考えましたが、複雑な設計になることは避けられません。やめたほうがいいです。


## マイグレーションファイルの生成が面倒

マイグレーションファイルをスキーマから生成する手順は面倒です。

https://noh.ink/articles/cdnuIsO3dLOpIHcFkO2d#Prisma%E3%81%AE%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AB%E5%BE%93%E3%81%A3%E3%81%A6%E3%80%81%E6%9C%80%E5%88%9D%E3%81%AE%E3%83%9E%E3%82%A4%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

毎回自分で空のマイグレーションファイルを生成し、そのファイルやスキーマファイルを引数に入れたコマンドを実行してマイグレーションファイルを生成する必要があります。

コレだけでも面倒ですが、さらにマイグレーションを実際に行い、`npx prisma generate`コマンドで必要なファイルを生成し、TSサーバーをリスタートしてました。手順多すぎます。

`prisma db push`コマンド? [D1では使えません](https://developers.cloudflare.com/d1/tutorials/d1-and-prisma-orm/#4-create-a-table-in-the-database)。



# サイズが大きい

自分のアプリケーションでは問題になってませんでしたが、無視できないデメリットです。

以下のリンクによると2024年4月時点でWebassemblyファイルはgzip圧縮で約785KBあります。Cloudflare workersの無料プラン制限が1MBなので約8割を使用します。

https://github.com/prisma/prisma/discussions/23646#discussioncomment-9059560


# drizzleに移行して感じたこと

## 思ったよりも機能は十分な水準だった

SQLライクな薄いORMという認識だったので、Prismaよりも抽象度が低く不便だと言う思い込みがありました。

しかし、実際に使ってみるとPrismaライクなメソッドも用意されていて便利です。

https://orm.drizzle.team/docs/rqb

困ったことに、困ることがありません。
すごい勢いでシェアを伸ばしてるだけあります。


## batchに対応

公式で対応してくれています。
正直、コレだけでCloudflare D1と組み合わせる価値があります。

https://leaysgur.github.io/posts/2023/10/17/213948/


## マイグレーションは便利

一応書いておくとPrismaのマイグレーションも本来便利です。しかし、D1と組み合わせると多くの機能が使えなくなって不便に感じていました。

Drizzleもやってる事自体は変わりませんが、Prismaで必要だった一部ファイルの生成やTSサーバーの再起動をしなくても動くので少し楽です。


## Prismaに比べると情報は少ない

使われてる期間が全く違うのでコレは仕方ないですね。Star数とかを見るとDrizzleも猛追しているので今後期待は高いです。

D1とDrizzle Queriesを組み合わせる方法がわからなくてハマりました。

https://noh.ink/articles/muifqvRbHeocThFXkA9J

サンプルとか見てもDrizzle Queriesと組み合わせたものがまったくないんですよね。すると、AIもうまく回答できません。

コードや型、ドキュメント見てたら解決したので良かったです。



# まとめ

Drizzleは非常に便利でした。

当初、Cloudflare d1のチュートリアルを読んでPrismaを使えることが書かれていたので、Prismaを選択したのですが失敗でした。

CloudflareとしてはD1という新しいプロダクトを宣伝するために、シェアの高いPrismaで使えることを宣伝したかったのだと思います。
そのためにPrismaに積極的に機能追加していたようですが、最近はあまり活発に動いているように見えません（多分ね）。
DrizzleなどD1により相性の良いORMがシェアを伸ばしたことで、無理にPrismaにこだわらなくて良くなったのかなと思います。

CloudflareはもっとDrizzleを宣伝してほしいですね。

Cloudflare d1 + Prisma をやめて Drizzle orm に移行した

JavaScriptの論理演算子とnull合体演算子について説明します。

## 主要な演算子

**|| (論理OR)**
```javascript
const result = a || b;
```
- `a`がfalsyな値（false, 0, "", null, undefined, NaN）なら`b`を返す
- `a`がtruthyなら`a`を返す

**&& (論理AND)**
```javascript
const result = a && b;
```
- `a`がfalsyなら`a`を返す
- `a`がtruthyなら`b`を返す

**?? (null合体演算子)**
```javascript
const result = a ?? b;
```
- `a`がnullまたはundefinedなら`b`を返す
- それ以外は`a`を返す

## 実際の使用例

```javascript
// デフォルト値の設定
const name = user.name || "匿名";  // 空文字でも"匿名"になる
const name2 = user.name ?? "匿名"; // nullやundefinedの時のみ"匿名"

// 条件付き実行
isLoggedIn && redirectToHome(); // ログイン済みなら実行

// 数値の場合の違い
const count = 0;
console.log(count || 5);  // 5 (0はfalsyなので)
console.log(count ?? 5);  // 0 (0はnullでもundefinedでもないので)
```

## その他の似た演算子

**||= (論理OR代入)**
```javascript
x ||= y;  // x = x || y; と同じ
```

**&&= (論理AND代入)**
```javascript
x &&= y;  // x = x && y; と同じ
```

**??= (null合体代入)**
```javascript
x ??= y;  // x = x ?? y; と同じ
```

**? : (三項演算子)**
```javascript
const result = condition ? valueIfTrue : valueIfFalse;
```

## 使い分けのポイント

- **||**: 任意のfalsyな値に対してデフォルト値を設定したい場合
- **??**: null/undefinedの時のみデフォルト値を設定したい場合（0や空文字は有効な値として扱いたい）
- **&&**: 条件が真の時のみ何かを実行したい場合

特に`||`と`??`の違いは重要で、0や空文字を有効な値として扱う必要がある場合は`??`を使うのが適切です。

JavaScriptの||, &&, ?? 演算子の使い分け（論理演算子, null合体演算子）

> クリーンアーキテクチャではドメイン層がインフラ層に依存しないことがメリットになっていますが、このメリットがわかりません。私はRailsプロジェクトに長く関わっており、モデルやDBにビジネスロジックが強く依存していることで困ったことはあまりありません。

Answer  by AI

Railsの開発経験が豊富な方なら、その疑問はとても自然だと思います。Railsは「設定より規約」の思想で、フレームワークが提供する構造に従って開発することで、多くのプロジェクトで十分に機能するアーキテクチャを実現できます。

クリーンアーキテクチャの依存関係の逆転が価値を発揮するのは、主に以下のような状況です：

**複数のデータソースを扱う場合**
例えば、顧客データを既存のRDBから取得しつつ、外部APIからも補完情報を取得し、さらにRedisにキャッシュするような複雑なシステムでは、ドメイン層が特定のデータソースに依存していると、データの取得方法を変更する際に影響範囲が広がります。

**長期運用での技術的負債の蓄積**
Railsプロジェクトでも、年月が経つにつれてActiveRecordモデルが肥大化し、ビジネスロジックとデータアクセスロジックが密結合になって、テストが困難になったり、仕様変更時の影響範囲が予測しにくくなることがあります。

**チーム規模の拡大**
小規模なチームでは問題にならなくても、チームが大きくなると、ドメイン知識を持つ人とインフラ詳細を知る人が分かれることがあり、その際に依存関係が明確に分離されていると、並行開発がしやすくなります。

ただし、多くのRailsプロジェクトでは、フレームワークの恩恵を受けつつ、Service ObjectやFormオブジェクトなどでビジネスロジックを適度に分離する程度で十分な場合が多いのも事実です。クリーンアーキテクチャは、複雑さとのトレードオフを慎重に検討して採用すべきアプローチだと言えるでしょう。

クリーンアーキテクチャでドメイン層がインフラ層に依存しないメリットがあるケース

例えば、あるpostレコードに紐づくpost contents一覧の中で、is_current == trueなカラムは1つまでに制限したい。

```ts
export const postContents = t.sqliteTable(
  "post_contents",
  {
    id: t.text().primaryKey(),
    postId: t
      .text("post_id")
      .notNull()
      .references(() => posts.id),
    isCurrent: t
      .integer("is_current", { mode: "boolean" })
      .notNull()
      .default(false),
    ...timestamps,
  },
  (table) => [
    t
      .uniqueIndex("post_contents_current_unique")
      .on(table.postId)
      .where(sql`${table.isCurrent} = true`),
  ],
)

```


以下のようなSQLが発行される

```sql
CREATE UNIQUE INDEX `post_contents_current_unique`
ON `post_contents` (`post_id`)
WHERE `is_current` = 1;
```

DrizzleとSQLite (d1) で条件付きユニーク制約

DrizzleでもrailsなどのようにcreatedAtやupdatedAtを自動的に設定したい。

今回はSQLiteもしくはCloudflare d1を使用しているとする。



# 結論

`.$defaultFn`や`.$onUpdateFn`を使ってアプリケーション側で日時を設定する方法が個人的に良さそうであった。

https://orm.drizzle.team/docs/column-types/sqlite#default-value

DB側でSQLを使って更新する方法が検索するとよく見つかったが、自動更新はSQLでカラムに値を入れて、手動で更新時はJS（TS）でカラムに値を入れるみたいなことをするのは2重管理のようで面倒に感じた。
SQLiteは動的な型システムを採用していて異なる型の値を入れてもエラーにならないことがあるので、アプリケーション側からの書き込みに統一したほうが整合性取りやすいと思う。



## カラムがtext型のパターン

日時のカラムの型はtext型とinteger型の2パターン選択肢がある。
個人的にはtext型のほうが好み。DBを見たときにわかりやすいし、ソートも問題なくできる。ソートのパフォーマンスはinteger型のほうがいいかもしれないが、計測したことはない。

DrizzleでDateをtextカラムに自動変換してくれる機能はデフォルトでないため、customTypeで作成する必要がある。

参考
https://www.memory-lovers.blog/entry/2025/01/04/173628

issueは経っているが、公式での対応はしばらくなさそうである。

```ts
const isoDateTime = t.customType<{
  data: Date // type of TypeScript
  driverData: string // type of DB
}>({
  dataType: (): string => "text", // type of DB
  toDriver: (value: Date): string => value.toISOString(), // TypeScript -> DB
  fromDriver: (value: string): Date => new Date(value), // DB -> TypeScript
})

const timestamps = {
  createdAt: isoDateTime("created_at")
    .notNull()
    .$defaultFn(() => new Date()),
  updatedAt: isoDateTime("updated_at")
    .notNull()
    .$defaultFn(() => new Date())
    .$onUpdateFn(() => new Date()),
}

export const posts = t.sqliteTable(
  "posts",
  {
    id: t.text().primaryKey(),
    slug: t.text().notNull().unique(),
    ...timestamps,
  },
)
```




## カラムがinteger型のパターン

integer型のときは`mode: "timestamp_ms"`を指定することでDate型を自動的に変換してくれる。
integer型でカラムに数字が入る。



```ts
const timestamps = {
  createdAt: t
    .integer("created_at", { mode: "timestamp_ms" })
    .notNull()
    .$defaultFn(() => new Date()),
  updatedAt: t
    .integer("updated_at", { mode: "timestamp_ms" })
    .notNull()
    .$defaultFn(() => new Date())
    .$onUpdateFn(() => new Date()),
}

export const posts = t.sqliteTable(
  "posts",
  {
    id: t.text().primaryKey(),
    slug: t.text().notNull().unique(),
    ...timestamps,
  },
)
```


# SQLiteではイマイチだった方法

個人的に上記の方法がより良いと感じただけで、当然この実装も問題はない。

## sql(CURRENT_TIMESTAMP)

```ts
.default(sql`(CURRENT_TIMESTAMP)`)
```

公式ドキュメントではこの方法が紹介されている。
カラムのtypeがtextのときに使えます。integerのカラムで使うと、読み込み時にInvalidDateになります。
SQLiteはintegerカラムに文字列を入れてもエラーになりません。

https://orm.drizzle.team/docs/column-types/sqlite#text



## sql(strftime('%s', 'now'))

```ts
.default(sql`(strftime('%s', 'now'))`)
```

問題なさそうではあるが、DB側で値が設定されアプリケーション側から`.set`メソッドで日時を設定するときと異なる方法になってしまう。
常にアプリケーション側で設定したほうが管理が楽だと思う。


Drizzle orm でcreatedAtとupdatedAtを自動設定する

Drizzleでレコードを取得するとき、DrizzleクエリやSQL Selectなどの方法があります。


https://orm.drizzle.team/docs/rqb

https://orm.drizzle.team/docs/select

DrizzleクエリはPrismaライクなメソッドで、SQL Selectはより生のSQLに近いメソッドです。

Cloudflare d1と組み合わせるドキュメントではSQL Selectが使われている例が書かれています。

実際に以下のようなコードを書いてみると`.posts`の部分でエラーになります。

```ts
const db = drizzle(c.env.DB)

await db.query.posts.findMany()
```

```
Property 'posts' does not exist on type 'DrizzleTypeError<"Seems like the schema generic is missing - did you forget to add it to your DB type?">'.ts(2339)
```

Drizzleクエリを使った例が全く見つからないので対応してないのかと思いましたが、違いました。
以下のように第2引数でschemaを渡せばよかったです。


```ts
import * as schema from "../../../db/schema"

const db = drizzle(c.env.DB, { schema })

await db.query.posts.findMany()
```

Cloudflare D1とDrizzleを組み合わせているときにDrizzleクエリを使用する

Claude api を使用する際は公式サイトの上のAPIの部分にログインリンクがある

https://www.anthropic.com/api

https://claude.ai/ の方には設定が見当たらない。



![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/3CAKdwttob7xPWZmwUPK/origin.webp)



有料のクレジットを購入しようとすると Business tax ID という項目がある。個人事業主はどうすればいいだろうか。

選択肢は以下の通り

- Japanese Corporate Number
- Japanese Registered Foreign Businesses’ Registration Number
- Japanese Tax Registration Number

上2つは法人用の項目と思われる。
Japanese Tax Registration Numberが何かよくわからないが、placeholder例が`T1234...`のようになっていて、Tから始まる番号ということは適格請求書発行事業者番号（インボイス番号）だろうか。
番号があるなら入力して、非課税事業者なら空欄のままで良さそう。

Claude api利用時のBusiness tax IDについて

GPTの回答
`.at`は普通に知らなかった。

TypeScript では、配列の `n` 番目の要素を取得すると `undefined` になる可能性がありますが、それでも型推論では `undefined` が含まれないのは、TypeScript の型システムの設計によるものです。  

### **理由 1: TypeScript は「配列は要素が存在する」と仮定する**
TypeScript は、`array[n]` の型を `T[]` 型から推論するときに、基本的に「`n` は有効なインデックスである」と仮定します。  
例えば、次のコードでは `numbers[2]` の型は `number` になります。

```ts
const numbers = [1, 2, 3]; // 型は number[]
const value = numbers[2];  // 推論結果: number
```
これは TypeScript の型推論が「通常、配列の有効なインデックスを使う」ケースを想定しているためです。  
`numbers[100]` は `undefined` ですが、これは実行時の動作であり、型推論には影響しません。

---

### **理由 2: `undefined` を含めると不便になる**
もし TypeScript が `numbers[n]` の型を `number | undefined` と常に推論すると、すべての配列アクセス時に `undefined` の可能性を考慮する必要があり、過剰な型安全チェックが求められることになります。

```ts
const numbers = [1, 2, 3];
const value: number | undefined = numbers[2]; // 厳密にはこうなるべき？

if (value !== undefined) {
  console.log(value.toFixed(2)); // OK
} else {
  console.log('Value is undefined');
}
```
しかし、通常の配列アクセスでは `undefined` になることは例外的なケースであり、多くの場合、開発者が手動でチェックする方が合理的です。

---

### **理由 3: 厳密に `undefined` を考慮するには `at()` を使う**
TypeScript 4.9 以降では、配列の `at()` メソッドを使うと `undefined` を含む型が推論されます。

```ts
const numbers = [1, 2, 3];
const value = numbers.at(5); // 推論結果: number | undefined
```
これは、`at()` が `undefined` を返すことを明示的に考慮しているためです。  
通常の `array[n]` のアクセスは「範囲内のアクセスが前提」とされているため、`undefined` を含みません。

---

### **結論**
- `array[n]` の型推論では `undefined` を含めないのが TypeScript のデフォルト仕様。
- すべてのアクセスに `undefined` を考慮すると使い勝手が悪くなるため。
- `at()` を使えば `undefined` を含む型推論になるため、厳密に扱いたい場合は `at()` を使うのが推奨される。

つまり、**「実行時には `undefined` になる可能性がある」ことと、「型システムが `undefined` を含めるかどうか」は別問題** ということですね。

TSで配列のn番目を取得したときの推定にはundefinedが入らない理由

今回はNodeのイメージを使う。

# 結論

```Docker
FROM node:20.12.2

WORKDIR /app

RUN echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list \
    && curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg \
    && apt-get update -y \
    && apt-get install google-cloud-cli -y
```

# ソース

https://cloud.google.com/sdk/docs/install?hl=ja

わざわざDockerにインストールするときの説明をしてくれている。

> Docker のヒント: Docker イメージ内に gcloud CLI をインストールする場合は、代わりに 1 回の実行ステップを使用します。
> 
> ```bash
> RUN echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list && curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg && apt-get update -y && apt-get install google-cloud-cli -y
> ```


イメージによってはsudo が使えないので自分の場合は消してた。

`curl: (23) Failed writing body`のようなエラーが出る。


Docker環境にGoogle Cloud CLIをインストールする

しばらく前にCloud Functions for Firebase V2 が発表されて移行がおすすめされていたが、テスト環境が整ってなく移行を先延ばしにしていました。

久々にIssueを確認していると完全な解決策ではないが、any型で一部パラメータをキャストするハックが紹介されてました。
その覚書です。

```ts
import { describe, it, expect, beforeAll, afterEach } from "vitest";
import firebaseFunctionsTest from "firebase-functions-test";

const tester = firebaseFunctionsTest({
  projectId: "demo-project",
});

describe("myFunction", () => {
  afterEach(() => {
    tester.cleanup();
  });

  it("should return the UID when called with authentication", async () => {
    const auth = {
      uid: "test-user-123",
    };

    const wrapped = tester.wrap(myFunction);

    const result = await wrapped({
      data: {},
      auth,
    } as any);
    expect(result).toBe("test-user-123");
  });
});
```

ちなみにimportなどを使うために`esModuleInterop: true` にしています。

```json
{
  "compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
```


以下、引用。


> v2の完全なサポートはほぼ完了しています。呼び出し可能オブジェクト（）にはまだ問題があります`.onCall`。[@tpiaggio](https://github.com/tpiaggio)直前に、次のように「キャスト」する必要があります。
> 
> const wrapped = wrap(myCallable);
> await wrapped({
>   data: {
>     'foo': 'bar',
>   },
> } as any); // here
> 次のコンパイル エラーが発生するためです。
> 
> ```
> Property rawRequest is missing in type { data: { foo: string; }; } but required in type CallableRequest<any>
> ```
> 
> 確かに、テスト ライブラリとしては、rawRequest をパラメータとして渡すことは望ましくありません (これは、現時点では型指定では必須です)。
> 
> https://github.com/firebase/firebase-functions-test/issues/163#issuecomment-2408687931


引き続き、以下のIssueを確認したい。

https://github.com/firebase/firebase-functions-test/issues/257

Cloud Functions for Firebase V2 の単体テスト型エラー


# 結論

課金の割り当ての増加リクエストはせずに、請求先アカウント自体を追加するのがよさそう。特に個人開発では。



# 1つの請求先アカウントに紐づけられるプロジェクト数は5つまで

Google Cloud Platform（GCP 最近はGCらしい）やFirebaseでサービスを運営している中で、Cloud functionsやKMSなど一部のサービスを使用するためにはプロジェクトに請求先アカウントを紐づけなければいけません。

しかし、1つの請求先アカウントに紐づけられるプロジェクト数は5つだけです。

> 課金の有料化エラー
> 
> 課金を有効にできるプロジェクトの上限に達しています。他プロジェクトで課金が必要なプロジェクトがさらにある場合は、課金の割り当ての増加をリクエストできます。

のようなエラーが出ます。

個人開発で使ってますが、基本的に1つのサービスにつきStaging環境とProduction環境の2つは使用しています
（FirebaseなどEmulatorで使えない機能もあったりするので場合によってはDevelopmant環境も必要だったりします）
すると5つなんてあっという間に到達してしまいます。

正直これは厳しい。



# 割り当て増加のリクエストにはお金がかかる？

追加のリクエストをしろと`Google Cloud Platform/API Project: Request Billing Quota Increase`というページに案内されるのですが、申請フォームを書いていると、以下の一文が表示されてることに気づきました。

> Depending on your GCP history, you may need to make additional payments. Make sure you monitor the billing account owner email address for further communication.
> 
> https://support.google.com/code/contact/billing_quota_increase?hl=ja

翻訳すると

> GCP の履歴によっては、追加の支払いが必要になる場合があります。今後の連絡のために、請求先アカウント所有者のメールアドレスを必ず監視してください。

だそうです。ナンテコッタ、パンナコッタ。
（パンナコッタが何か知らないですが、きっとシュークリームのパチモンみたいなやつです。）

さて、対して収入もない個人開発で課金がかさむのは困ります。ビビッて調べるといくつか前例が見つかります。

https://dev.classmethod.jp/articles/gcp-billing-quota-increase/

こちらはクラスメソッドさんの事例。請求先アカウントのプロジェクト数上限緩和申請をして実際に緩和されたみたいです。
50ドル請求されてますが、クレジットとして戻ってきたようです。
Googleとしては不正対策の一環くらいの制限なんでしょうかね。

https://jsnotice.com/posts/2022-09-12/

こちらは個人のブログ。ここで初めて複数の請求先アカウントが作れることに気づきます。ハイジタッタ。

クレジットカードも同じものが選択できますし、サービスごとに請求先を分かれることで、サービスごとのコストもわかりやすくなりました。

また何か、メリットデメリット感じたら追記します。


GCPやFirebaseで請求先アカウントに登録できるプロジェクトの数が5個以上になるときは申請せずにアカウントを追加する

https://github.com/panva/jose

GPT君の説明がわかりやすかった。

generateSecret の extractable オプションは、生成した秘密鍵をエクスポートできるかどうかを制御するフラグです。

# extractable の意味

extractable を true にすると、秘密鍵を JWK 形式などでエクスポート できるようになります。
false にすると、エクスポートが禁止され、外部に取り出せなくなります。

```ts
const secret = await jose.generateSecret("HS256", { extractable: false });

```

- extractable: true（デフォルト） → exportJWK でエクスポート可能
- extractable: false → exportJWK でエラーが発生する（秘密鍵を外部に漏らさない）

# extractable: false の影響

## JWK エクスポートの可否

```ts
import * as jose from "jose";

(async () => {
  const secret = await jose.generateSecret("HS256", { extractable: false });

  try {
    const jwk = await jose.exportJWK(secret);
    console.log("JWK:", jwk);
  } catch (error) {
    console.error("エクスポート失敗:", error.message);
  }
})();

```

✅ extractable: true

```ts
JWK: { kty: 'oct', k: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx' }

```

✖ extractable: false（デフォルト）

```ts
エクスポート失敗: The provided key is not extractable
```

このように、エクスポートが禁止されます。


## 秘密鍵の再利用

`extractable: false` にすると、一度生成した鍵を exportJWK で外部に保存できないため、環境変数やデータベースに保存できず、再利用が難しくなります。
したがって、短期間だけ使う鍵（例: メモリ上での一時的な暗号化処理）に向いています。

# いつ extractable: false を使うべきか？

- extractable: trueを使うケース
  - 秘密鍵を環境変数や DB に保存して再利用したい場合
  - JWK 形式でエクスポートして別のシステムで使用したい場合
- extractable: false（デフォルト） を使うケース
  - メモリ上で一時的に鍵を作成し、外部に漏れないようにしたい場合
  - セキュリティを強化し、鍵を絶対にエクスポートさせたくない場合


# まとめ

| extractable | 説明 | エクスポート可否 | 用途 
| -- | -- | -- | -- |
| true | 秘密鍵をエクスポート可能 | ✅ JWK でエクスポート可 | 環境変数や DB に保存し再利用 |
| false（デフォルト） | エクスポート禁止 | ❌ JWK 取得不可 | 一時的な鍵（外部に漏らさない用途） |

[ panva / jose ] generateSecret の extractable オプションについて

Hono + Cloudflare d1 + workers/pages でWebアプリを作ります。

Cloudflare workers/pagesのどちらを選べばいいのかは難しいですが、静的アセット配信があるならPagesが良いらしいです（Workersにも似た機能が追加されてたと思いますが）。
API作るときはWorkers、Webサイト作るときはPagesだと思います。基本的に自分はWebサイト作るときはHonoじゃなくてAstro使ってます。

WorkersとPagesは統合が進んでますが、どちらかが使えなくなるような予定はないらしいです。

https://zenn.dev/yusukebe/articles/92fcb0ef03b151

今回はWorkersを使いますが、Pagesもhono createでpagesを選択すれば同じようにできるはずです。

ORMはDrizzle ORMが最近人気ですが、ActiveRecordになれた自分はPrismaの方が好みでした。歴史が長くある程度成熟してますし、楽な方が良いです。


# 参考になるリンク

参考になるドキュメントは以下です。

基本的にはCloudflare workers/pagesのドキュメントとHonoのGet Startedに沿って進めるだけです。Honoのドキュメントは洗練されていて悩むところは無いと思います。Prismaのマイグレーションに関わる部分だけそれらのドキュメントが少ないので、Prisma公式ドキュメントが参考になります。

Hono の公式ドキュメント Cloudflare Workers用 Getting Started


https://hono.dev/docs/getting-started/cloudflare-workers


Hono 公式 Cloudflare Testing

https://hono.dev/examples/cloudflare-vitest

Cloudflare 公式ドキュメント Query D1 from Hono

https://developers.cloudflare.com/d1/examples/d1-and-hono/

Query D1 using Prisma ORM

https://developers.cloudflare.com/d1/tutorials/d1-and-prisma-orm/

Prisma 公式ドキュメント Cloudflare D1

https://www.prisma.io/docs/orm/overview/databases/cloudflare-d1


# Honoプロジェクトの作成

`npm create hono@latest`コマンドでプロジェクトを作成します。
honoは`Target directory .`とすることで、現在いるディレクトリにファイルを展開してくれるので便利です。

```bash
$ cd repo_name
$ npm create hono@latest
create-hono version 0.15.3
? Target directory .
? Which template do you want to use?
cloudflare-workers
? Directory not empty. Continue? yes
? Do you want to install project dependencies? yes
? Which package manager do you want to use? npm
✔ Cloning the template
✔ Installing project dependencies
🎉 Copied project files
Get started with: cd .
```

するといくつかファイルが生成されます。

```json:package.json
{
  "name": "repo_name",
  "scripts": {
    "dev": "wrangler dev",
    "deploy": "wrangler deploy --minify"
  },
  "dependencies": {
    "hono": "^4.7.1"
  },
  "devDependencies": {
    "@cloudflare/workers-types": "^4.20250109.0",
    "wrangler": "^3.101.0"
  }
}
```

```json:tsconfig.json
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "skipLibCheck": true,
    "lib": [
      "ESNext"
    ],
    "types": [
      "@cloudflare/workers-types/2023-07-01"
    ],
    "jsx": "react-jsx",
    "jsxImportSource": "hono/jsx"
  },
}
```

```json:wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "repo_name",
  "main": "src/index.ts",
  "compatibility_date": "2025-02-18"
  // "compatibility_flags": [
  //   "nodejs_compat"
  // ],
  // "vars": {
  //   "MY_VAR": "my-variable"
  // },
  // "kv_namespaces": [
  //   {
  //     "binding": "MY_KV_NAMESPACE",
  //     "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  //   }
  // ],
  // "r2_buckets": [
  //   {
  //     "binding": "MY_BUCKET",
  //     "bucket_name": "my-bucket"
  //   }
  // ],
  // "d1_databases": [
  //   {
  //     "binding": "MY_DB",
  //     "database_name": "my-database",
  //     "database_id": ""
  //   }
  // ],
  // "ai": {
  //   "binding": "AI"
  // },
  // "observability": {
  //   "enabled": true,
  //   "head_sampling_rate": 1
  // }
}
```

`npm run dev`で起動できます。



# テストを書く Vitestとcloudflare/vitest-pool-workersの導入

Cloudflare workersのテストはcloudflare/vitest-pool-workersを使用するのがよさそうなのでインストールします。その際、明示的にVitestもインストールすることが推奨されてます。
2025/02現在、cloudflare/vitest-pool-workersがVitest3に対応してないので、バージョン2を使ってます。そのうち対応すると思うので、バージョン3に対応してるか確認してください。

以下のコマンドでインストールします。

```bash
$ npm i -D @cloudflare/vitest-pool-workers
$ npm install -D vitest@v2.1.9
```

```json:package.json
{
  "name": "repo_name",
  "scripts": {
    "dev": "wrangler dev",
    "test": "vitest",
    "deploy": "wrangler deploy --minify"
  },
  "dependencies": {
    "hono": "^4.7.1"
  },
  "devDependencies": {
    "@cloudflare/vitest-pool-workers": "^0.6.16",
    "@cloudflare/workers-types": "^4.20250109.0",
    "vitest": "^2.1.9",
    "wrangler": "^3.101.0"
  }
}
```

テストのimport部分で型エラーが出るので、tsconfig.json に`"@cloudflare/vitest-pool-workers"`を追加します。
includesやexcludesは不要です。

```json:tsconfig.json
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "skipLibCheck": true,
    "lib": ["ESNext"],
    "types": [
      "@cloudflare/workers-types/2023-07-01",
      "@cloudflare/vitest-pool-workers"
    ],
    "jsx": "react-jsx",
    "jsxImportSource": "hono/jsx"
  }
}
```

最初のテストを書きます。

```ts:src/index.test.ts
import { describe, it, expect } from "vitest";
import { env } from "cloudflare:test";
import app from "./index";

describe("Example", () => {
  it("Should return 200 response", async () => {
    const res = await app.request("/", {}, env);

    expect(res.status).toBe(200);
    expect(await res.text()).toEqual("Hello Hono!");
  });
});
```

`npm run test`でテストが実行されます。


# CI の設定

Github Actionsを使ってテストが自動実行されるようにします。

react-dropzone-vvで使ってる設定の使いまわしです。

https://github.com/yosipy/react-dropzone-vv

```yml:.github/workflows/ci.yml
name: CI

on:
  push:

jobs:
  ts-test:
    name: TS Test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Cache node modules
        uses: actions/cache@v4
        id: node_modules_cache_id
        env:
          cache-name: cache-node-modules
        with:
          path: ./node_modules
          key: ${{ runner.os }}-npm-${{ env.cache-name }}-${{ hashFiles('./package-lock.json') }}
      - name: npm ci
        if: ${{ steps.node_modules_cache_id.outputs.cache-hit != 'true' }}
        run: |
          npm ci
      - name: Run test
        run: |
          npm run test
```



# Cloudflare d1とPrisma


まず、必要なPackageをインストールします。

```bash
$ npm install prisma --save-dev
$ npm install @prisma/client
$ npm install @prisma/adapter-d1
```

```json:package.json
  "dependencies": {
    "@prisma/adapter-d1": "^6.4.0",
    "@prisma/client": "^6.4.0",
    "hono": "^4.7.1"
  },
  "devDependencies": {
    "@cloudflare/vitest-pool-workers": "^0.6.16",
    "@cloudflare/workers-types": "^4.20250109.0",
    "prisma": "^6.4.0",
    "vitest": "^2.1.9",
    "wrangler": "^3.101.0"
  }
```

`npx prisma init`コマンドを使って`prisma/schema.prisma`を生成します。

```bash
$ npx prisma init --datasource-provider sqlite
```

```ts:prisma/schema.prisma
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}
```

プレビュー版の機能を使うために、`previewFeatures = ["driverAdapters"]`を追加します。

```diff
generator client {
  provider        = "prisma-client-js"
+ previewFeatures = ["driverAdapters"]
}
```

## d1の設定

Cloudflare d1の管理画面から新しいDBを作成します。
database_nameとdatabase_idが表示されるので、wrangler.jsoncへ追加します。

```json:wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "repo_name",
  "main": "src/index.ts",
  "compatibility_date": "2025-02-18",
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "test_db",
      "database_id": "xxxxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx"
    }
  ]
```

## Prismaのドキュメントに従って、最初のマイグレーション

https://www.prisma.io/docs/orm/overview/databases/cloudflare-d1

Cloudflare d1はprisma migrate devコマンドに対応してないので、prisma migrate diff コマンドを使います。

今回は以下のようなユーザーテーブルを追加するマイグレーションを行います。

```
model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}
```
prisma/schema.prisma に追加します。

```ts:prisma/schema.prisma
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
}
```

wrangler を使ってマイグレーションファイルを作成します。

```bash
npx wrangler d1 migrations create __YOUR_DATABASE_NAME__ create_user_table
```

すると、空の`migrations/0001_create_user_table.sql`が作成されます。

`migrations/0001_create_user_table.sql`へSQLを生成します。`prisma migrate diff`コマンドを使って`prisma/schema.prisma`から生成します。

```
$ npx prisma migrate diff \
  --from-empty \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output migrations/0001_create_user_table.sql
```

migrations/0001_create_user_table.sql は以下のようになります。

```sql:migrations/0001_create_user_table.sql
-- CreateTable
CREATE TABLE "User" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "email" TEXT NOT NULL,
    "name" TEXT
);

-- CreateIndex
CREATE UNIQUE INDEX "User_email_key" ON "User"("email");

```

マイグレーションは以下のコマンドで適用します。

ローカルに適用する場合は

```bash
$ npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --local
```

リモートに適用する場合は

```bash
$ npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --remote
```



## 2回目以降のマイグレーション

初回と同じコマンドを使用すると同じファイルが上書きされてしまうので、コマンドを少し変えます。

公式ドキュメントと同様にPostテーブルを追加します。

```ts:prisma/schema.prisma
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}

model Post {
  id       Int    @id @default(autoincrement())
  title    String
  author   User   @relation(fields: [authorId], references: [id])
  authorId Int
}
```

空のマイグレーションファイルを作成します。

```bash
$ npx wrangler d1 migrations create __YOUR_DATABASE_NAME__ create_post_table
```

`migrations/0002_create_post_table.sql`が作成されます。

```bash
$ npx prisma migrate diff \
  --from-local-d1 \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output migrations/0002_create_post_table.sql
```

以下のようにSQLが生成されます。

```sql:migrations/0002_create_post_table.sql
-- CreateTable
CREATE TABLE "Post" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "title" TEXT NOT NULL,
    "authorId" INTEGER NOT NULL,
    CONSTRAINT "Post_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "User" ("id") ON DELETE RESTRICT ON UPDATE CASCADE
);

```

マイグレーションは以下のコマンドで適用します。

ローカルに適用する場合は

```bash
$ npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --local
```

リモートに適用する場合は

```bash
$ npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --remote
```

## ローカルのDBを削除したいとき

`.wrangler/state/v3/d1/miniflare-D1DatabaseObject/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.sqlite`のようなファイルを削除します。

# d1と通信するHono api

試しにPostでユーザーを追加し、Getでユーザー一覧を取得するAPIを追加します。

```ts:index.ts
import { Hono } from "hono";

import { PrismaClient } from "@prisma/client";
import { PrismaD1 } from "@prisma/adapter-d1";

type Bindings = {
  DB: D1Database;
};

const app = new Hono<{ Bindings: Bindings }>();

app.get("/users", async (c) => {
  const adapter = new PrismaD1(c.env.DB);
  const prisma = new PrismaClient({ adapter });

  const users = await prisma.user.findMany();

  return c.json(users);
});

app.post("/users", async (c) => {
  const adapter = new PrismaD1(c.env.DB);
  const prisma = new PrismaClient({ adapter });
  const user = await prisma.user.create({
    data: {
      email: "elsa@prisma.io",
      name: "Elsa Prisma",
    },
  });

  return c.json(user);
});

export default app;

```

以下のコマンドを実行して、APIをたたくと結果が返ってきます。

```bash
$ npx prisma generate
```



Hono + Cloudflare d1 + workers/pages + Prisma で作るWebアプリ

# <input type="datetime-local">



![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/z3zxLicEotN02jMdOjeS/origin.webp)

Reactではないですが、Reactでも利用可能です。
Timezoneの機能は様々な要因で削除されているので、タイムゾーン付きの時刻を取得したいのであれば、別の入力と組み合わせる必要があります（詳しくはリンク先を参照）。
パッケージに頼らない実装は長期的なメリットですが、拡張性は劣ります。
個人的には有力な選択肢です。


https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local


# react-datepicker

おそらくもっともメジャーな選択肢。
日付の選択のみで時間の選択はありません。

![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/JHP6ni19J3iVHnr4pttO/origin.webp)



https://reactdatepicker.com/

https://github.com/Hacker0x01/react-datepicker/


# react-tailwindcss-datepicker


![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/dBvA5W4llpbcFtynY36w/origin.webp)

ReactとTailwindcssを使用したDatePicker。
今日などを指定できるショートカットもありますし、日付範囲だけでなく単独日付の指定も可能です。
時間の指定はありません。

https://react-tailwindcss-datepicker.vercel.app/

https://github.com/onesine/react-tailwindcss-datepicker


# react-date-picker


![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/EYH2risUZLxOvy1520Nh/origin.webp)

日付選択用のパッケージだが、react-time-pickerも別パッケージとして提供していて連携させられるみたい。

https://projects.wojtekmaj.pl/react-date-picker/

https://github.com/wojtekmaj/react-date-picker

https://github.com/wojtekmaj/react-time-picker


# MUI X Date and Time Pickers

非常に高機能なDatePicker。
日付だけでなく時間の指定も可能です。
名前の通りMUIに依存しているので、MUIを使用しているプロジェクトでは選択肢になります。


![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/2LvnezTOr4mV53cZH23O/origin.webp)

![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/YsjrT61v9Olp9SjlxUaG/origin.webp)



https://mui.com/x/react-date-pickers/

https://github.com/mui/mui-x


# react-dates

2022年から更新されてないので選択肢から外れそう。

https://github.com/react-dates/react-dates


# react-datetime

2022年から更新されてないので選択肢から外れそう。
メンテナンスが終了したMoment.jsに依存しているのも影響が大きいです。


https://github.com/arqex/react-datetime

[React] 日時選択ライブラリ比較

Tailwind cssで全体の背景色を指定する方法です。

`bg-`で好きな色を指定したうえで、`min-h-[100vh]`で最小の高さを画面の高さに揃えます。

つまり、以下のDivで全体を囲めばいいです。

```ts
<div className="bg-neutral-200 min-h-[100vh]">
```



これを行うと`Navbar`などほかの要素も同じ背景色になってしまいますが、これば他の要素に色が指定されてなくて透明だからです。個別に背景色を指定すれば解決します。


![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/xuhXmayntuBu9g4PhZGI/origin.webp)

Tailwind cssで背景全体の色を指定

ブログ投稿サービスである[noh](https://noh.ink/)ではFirebaseを使っているが、Cloud Storageに保存されている画像はCloudflare CDN経由で配信しています。その方法の解説をします。

Firebaseを使っていないCloud Storageでも設定方法はほぼ同じです。


# Cloudflare CDNを使うメリット

- 安い
  - GCPからCloudflareへの通信料金は割引される（[ CDN Interconnect プログラム](https://cloud.google.com/network-connectivity/docs/cdn-interconnect?hl=ja)）
  - Cloudflare CDNは無料で使える。
- 比較的設定が簡単
  - GCPのCloud CDNを使うには多分ロードバランサの設定が必須（使ったことないので間違っていたらすいません）。CloudflareはCNAMEの設定などだけで勝手にキャッシュしてくれて比較的簡単だと思います。

今回はCloud Storage for Firebase を使っていますが、もっと安くしたいのであれば、代わりにCloudflare R2の使用を検討してもいいかもしれません。



# Q&A

## CDNの設定は必ず必要か

A: Cloud StorageはCDNの設定なしでもCDNのような挙動をしてくれるようです（とはいっても通信料金はそのままのはず）。大量のアクセスが無いアプリケーションではなくても困りません。しかし、CDNを経由させることでダウンロード速度の恩恵があったり、大量のアクセスがあったときに料金を安くできます。
また、後で画像のURLを変更しにくいなどの要件があれば早い段階で導入すべきだと思います。例えばこのブログではマークダウン内に画像URLが入っているので、後から画像URLを変更するのはかなり大変です。


## Firebaseのセキュリティルールはどうなるか

A: 今回、バケット内部のオブジェクトすべて（または一部）を公開する設定を行う方法を解説します。これによってFirebaseのセキュリティルールを無視してURLからreadできるようになります(ただし、writeについてはセキュリティルールで制御できます)。公開用のバケットは別のバケットを作成するといいです。

私はデフォルトのバケットを非公開用にしています。こちらはFirebaseのセキュリティルールを使ってreadしています。



# 設定のポイント

- 使用するドメインの所有権の証明が必要です。
- 配信に使用するサブドメインとバケット名は同じにする必要があります。



# 設定方法

## 配信に使用するサブドメインを決定

配信に使用するサブドメインを決定します。先に決めておく理由は、配信に使用するサブドメインとバケット名は同じにする必要があるからです。この記事では`storage-noh-production.noh.ink`とします。

公式ドキュメントにはこのあたりに書かれています。

https://cloud.google.com/storage/docs/request-endpoints?hl=ja#cname



## サブドメインのドメイン所有権の証明

Cloud Storageにサブドメインのバケットを作るためには、ドメイン所有権の証明を行う必要があります。これをせずにFirebaseのコンソール画面で作成を行うと失敗します（`バケットの作成中にエラーが発生しました`としか表示されないので、なんで失敗したかわかりませんでした）。

バケット名の要件のドキュメントに記載されています。

https://cloud.google.com/storage/docs/domain-name-verification?hl=ja

所有権の照明は[Serch console](https://search.google.com/search-console)から行います。基本的にはボタンをポチポチしていけば完了しますが、404が出たり失敗する場合は以下の方法に変更するといいかもしれません。

- 手順のとこで、「Cloudflare」から「任意のDNSプロバイダ」に変更して進める。DNSの設定は名前を`noh.ink`、コンテンツは表示されたTXT レコードを使います。私はこちらで設定しました。
- URL プレフィックスで設定する。サブドメインごとに設定が必要そうです。



## バケットの作成

バケットを追加します。注意点はサブドメイン名をバケット名にします。ここでは`storage-noh-staging.noh.ink`としました。
ロケーションは東京にするならasia-northeast1です。

私は、作成したバケット内のオブジェクトすべてを公開しています。バケット内のすべてのオブジェクトを公開すると、Firebaseのセキュリティルールも無視してアクセス可能になります。該当バケット内に公開したくないオブジェクトを追加しないように注意してください。

私はバケット内のオブジェクトすべてを公開していますが、バケットの一部だけ公開することもできるのでそちらでもいいと思います。

以下のドキュメント通りに設定するだけです。

https://cloud.google.com/storage/docs/access-control/making-data-public?hl=ja#buckets

意図しないファイルが公開されないように、注意して設定してください。



## DNSの設定

DNSにCNAMEを追加します。

| type | name | data |
| -- | -- | -- |
| CNAME | storage-noh-production | c.storage.googleapis.com |

ドキュメントには`c.storage.googleapis.com.`を設定するように書かれていますが、最後のドットは保存すると消えました。

https://cloud.google.com/storage/docs/request-endpoints?hl=ja#cname



## 確認

適当なファイルをFirebase console画面からアップロードします。

アップロードしたファイルにURL経由でアクセスします。
URLは`https://${storageBucketName}/${filePath}`のような感じで、以下の画像のURLは`https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/FJd0PZjcffz6wGdQhyUf/origin.webp`です。

![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/FJd0PZjcffz6wGdQhyUf/origin.webp)

画像を新しいタブで開いてResponse headersを見てみます。Cloudflare CDN関連のパラメータが確認できます。

![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/a05ukNpqyM9mYylXKDHl/origin.webp)

何度か再読み込みすると`cf-cache-status:HIT`となり、CDNのキャッシュから配信されていることが確認できました。

![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/iBNIlusovbgdJwyzoBAV/origin.webp)


# おまけ

## Emulatorを使っている場合について

アクセスするURLは`http://localhost:9199/storage-noh-production.noh.ink/${path}`のようになります。実際には開発環境から本番環境につなぐことはないと思うので、`storage-noh-production.noh.ink`の部分は`storage-noh-development.noh.ink`になると思います。


# 参考

https://cloud.google.com/storage/docs/request-endpoints?hl=ja

https://www.memory-lovers.blog/entry/2021/07/21/110000

Cloud Storage for Firebase でファイルをCloudflare CDN経由で配信する

Three.jsを使った個人的に重宝しているコード集です。

ベクトルAからベクトルBの回転、FPSの固定、複数のカメラを同時にレンダリング、TransformControls の大きさをオブジェクトに対して固定する方法など。



# ベクトルAからベクトルBの回転

追記

Three.jsにはデフォルトでこの機能がありました。

https://threejs.org/docs/#api/en/math/Quaternion.setFromUnitVectors

以下のように実行できます。
```ts
new THREE.Quaternion().setFromUnitVectors(
  fromVec.clone().normalize(),
  toVec.clone().normalize(),
)
```

追記終わり

個人的に重宝してる関数。

```ts
import * as THREE from "three"

export const quaternionAtoB = (a: THREE.Vector3, b: THREE.Vector3) => {
  const normalizedA = a.clone().normalize()
  const normalizedB = b.clone().normalize()

  // ベクトルAとベクトルBの間の軸と角度を計算
  const axis = new THREE.Vector3()
    .crossVectors(normalizedA, normalizedB)
    .normalize()
  const angle = Math.acos(normalizedA.dot(normalizedB))

  // 回転を表すクォータニオンを作成
  const quaternion = new THREE.Quaternion().setFromAxisAngle(axis, angle)
  if (isNaN(quaternion.x) || isNaN(quaternion.y) || isNaN(quaternion.z)) {
    return new THREE.Quaternion()
  }
  return quaternion
}
```



# FPSを制限する

FPSLimitter のオブジェクトを作成して、レンダリングループの中でisRenderingを使ってレンダリングするか分岐させます。

```ts
export class FPSLimitter {
  maxFPS: number
  lastFrameTime: DOMHighResTimeStamp

  constructor(maxFPS: number) {
    this.maxFPS = maxFPS
    this.lastFrameTime = performance.now()
  }

  isRendering() {
    const now = performance.now()
    const frameDuration = 1000 / this.maxFPS
    const delta = now - this.lastFrameTime

    if (delta > frameDuration) {
      this.lastFrameTime = now - (delta % frameDuration)

      return true
    }
    return false
  }
}

```

```ts
const fpsLimitter = new FPSLimitter(30)

const animate = () => {
  if (fpsLimitter.isRendering()) {
    renderer.render(scene, camera)
  }

  requestAnimationFrame(animate)
}
animate()
```



# FPSをログに表示

```ts
export class FPSLogger {
  frameCount: number
  prevTime: DOMHighResTimeStamp

  constructor() {
    this.frameCount = 0
    this.prevTime = performance.now()
  }

  update() {
    const currentTime = performance.now()
    this.frameCount++

    if (currentTime >= this.prevTime + 1000) {
      const fps = this.frameCount
      this.frameCount = 0
      this.prevTime = currentTime

      console.log("FPS: " + fps)
    }
  }
}
```

```ts
const fpsLogger = new FPSLogger()

const animate = () => {
  fpsLogger.update()

  requestAnimationFrame(animate)
}
animate()
```



# TransformControls の大きさをオブジェクトに対して固定する

ハックな解決方法になってしまう。
この関数を毎フレーム呼ぶ。

transformControlsPositionはGizmoの中心位置（ワールド座標）。`transformControls.object.getWorldPosition(new THREE.Vector3())`でも多分問題ない。

```ts
import * as THREE from "three"
import { TransformControls } from "three/addons/controls/TransformControls.js"

export const fixWorldSizeOfTransformControls = (
  transformControls: TransformControls,
  transformControlsPosition: THREE.Vector3,
  camera: THREE.PerspectiveCamera,
  baseSize: number,
) => {
  const distance = camera.position.distanceTo(transformControlsPosition)
  const fov = (camera.fov * Math.PI) / 180
  transformControls.setSize(baseSize / (Math.tan(fov / 2) * distance))
}
```



# ダブルクリックでOrbitControlsが壊れる

複数のカメラを使っているときに発生する？
どういった場合に発生するか詳しく検証していないが、以下の方法で解決できた。

```css
/* Disable text selection for all elements */
* {
  user-select: none;
  -moz-user-select: none; /* Firefox */
  -ms-user-select: none; /* Internet Explorer */
  -webkit-user-select: none; /* Chrome, Safari, Opera */
}

/* Allow text selection for elements with class "selectable" */
.selectable {
  user-select: auto;
}
```

参考: https://discourse.threejs.org/t/orbitcontrols-double-click-breaks-with-multiple-scenes/54229/6


Reactでインラインスタイル指定するなら以下のように。

```ts
    <div
      style={{
        userSelect: "none",
        MozUserSelect: "none" /* Firefox */,
        msUserSelect: "none" /* Internet Explorer */,
        WebkitUserSelect: "none" /* Chrome, Safari, Opera */,
      }}
    >
```


# 複数のカメラを同時に表示する

複数のCanvasを使用するのはいい方法ではないです。

Canvasの上にDiv要素を重ね、その中にカメラに対応するDiv要素を並べてレンダリングします。

```ts
function resizeRendererToDisplaySize(renderer: WebGLRenderer) {
  const canvas = renderer.domElement
  const width = canvas.clientWidth
  const height = canvas.clientHeight
  const needResize = canvas.width !== width || canvas.height !== height
  if (needResize) {
    renderer.setSize(width, height, false)
  }
  return needResize
}

function setScissorForElement(
  renderer: WebGLRenderer,
  elem: HTMLDivElement | null,
) {
  const canvas = renderer.domElement
  const canvasRect = canvas.getBoundingClientRect()
  const elemRect = elem.getBoundingClientRect()

  // compute a canvas relative rectangle
  const right = Math.min(elemRect.right, canvasRect.right) - canvasRect.left
  const left = Math.max(0, elemRect.left - canvasRect.left)
  const bottom = Math.min(elemRect.bottom, canvasRect.bottom) - canvasRect.top
  const top = Math.max(0, elemRect.top - canvasRect.top)

  const width = Math.min(canvasRect.width, right - left)
  const height = Math.min(canvasRect.height, bottom - top)

  // setup the scissor to only render to that part of the canvas
  const positiveYUpBottom = canvasRect.height - bottom
  renderer.setScissor(left, positiveYUpBottom, width, height)
  renderer.setViewport(left, positiveYUpBottom, width, height)

  // return the aspect
  return width / height
}
```

```ts
const renderer = new WebGLRenderer({
  canvas: canvasRef.current,
  antialias: true,
})
const scene = new Scene()

const animate = () => {
  resizeRendererToDisplaySize(renderer)
  renderer.setScissorTest(true)

  context.main.camera.aspect = setScissorForElement(
    renderer,
    mainRef.current,
  )
  context.main.camera.updateProjectionMatrix()
  renderer.render(scene, context.main.camera)

  context.sub.camera.aspect = setScissorForElement(
    renderer,
    subRef.current,
  )
  context.sub.camera.updateProjectionMatrix()
  renderer.render(scene, context.sub.camera)

  requestAnimationFrame(animate)
}
animate()
```

```tsx
<div
  style={{
    position: "relative",
    width: "100vw",
    height: "100vh",
  }}
>
  <canvas ref={canvasRef} style={{ width: "100%", height: "100%" }} />
  <div
    ref={splitedRef}
    style={{
      position: "absolute",
      left: 0,
      top: 0,
      width: "100%",
      height: "100%",
      display: "flex",
    }}
  >
    <div
      ref={subRef}
      style={{
        width: "40%",
        height: "100%",
      }}
    ></div>
    <div
      ref={mainRef}
      style={{
        width: "60%",
        height: "100%",
      }}
    ></div>
  </div>
</div>
```


# TransformControlsのGizmoObjectを取得

`transformControls._gizmo`で取得できなくはないが、プライベートな変数にアクセスするのはお行儀がよくない。個人的には以下のような感じで取得している。複数のGizmoをChildとして持たないはずなので問題はないが、少し変更に弱いコードになってしまう。

```ts
const transformControls = new TransformControls(camera, elem)

const getTransformControlsGizmo = (transformControls: TransformControls) => {
  // return this._gizmo
  for (const child of transformControls.children) {
    if (child instanceof TransformControlsGizmo) {
      return child as TransformControlsGizmo
    }
  }
  return undefined
}

getTransformControlsGizmo(transformControls)
```


Three.jsの便利なハック集

functionで定義した関数とアロー関数ではthisの動作が異なります。

「functionで定義した関数」が呼び出されるとき、その this は呼び出し元に依存します。例えば、イベントリスナー内で this を使用すると、通常はイベントが発生した要素や、グローバルオブジェクト（ブラウザ環境では window）を指します。

アロー関数は、this のスコープをその外側のスコープから継承します。アロー関数内の this は、アロー関数が定義された場所の this をそのまま使用します。これにより、アロー関数内で this の参照を変更せずに、外側の this を利用することができます。

# コード例

以下のコードは`Property 'mousedownPosition' does not exist on type 'Window'.`というエラーになります。
`this`は`Window`になっています。

```ts
export class ModelList extends THREE.Group {
  mousedownPosition: THREE.Vector2 | undefined

  constructor() {
    super()

    window.addEventListener("mousedown", function(event) {
      this.mousedownPosition = new THREE.Vector2(event.clientX, event.clientY)
    })
```

これを動作させようとすると以下のコードになります。アロー関数に変更すれば`this`はクラスオブジェクト自身になります。

```ts
export class ModelList extends THREE.Group {
  mousedownPosition: THREE.Vector2 | undefined

  constructor() {
    super()

    window.addEventListener("mousedown", (event) => {
      this.mousedownPosition = new THREE.Vector2(event.clientX, event.clientY)
    })
```

[JS] functionで定義した関数とアロー関数でthisの扱いは異なる

今回はViteで作ったパッケージにVitePressでドキュメントを作成する方法を解説します。

https://vitepress.dev/

リポジトリ例

https://github.com/yosipy/react-dropzone-vv



# Vitepressを導入する

インストールした後に初期化します。

```bash
npm add -D vitepress
```

```bash
npx vitepress init
```

初期化ではいくつか質問をされます。
VitePressのリポジトリは`./docs`を指定する以外に注意点はありません。

終わったら必要なファイルが生成され、package.jsonにコマンドが追加されます。

```json:package.json
  "scripts": {
    ...
    "docs:dev": "vitepress dev docs",
    "docs:build": "vitepress build docs",
    "docs:preview": "vitepress preview docs"
```

どこかのタイミングでキャッシュファイルが作られていたら随時gitignoreしてください。

```txt:.gitignore
.vite
docs/.vitepress/cache
```


# VitePressでページを表示する

詳しく説明しないので、ドキュメントを読んでください。難しくないです。
マークダウンを追加するとページを追加でき、「docs/.vitepress/config.ts」でヘッダーやサイドバーの内容を更新します。

以下のような現象があった。

https://noh.ink/articles/fquYwbOIueT38cv14N0V


# VitePressのページにReactのデモを表示する

VitePressの何が素晴らしいって、ドキュメント内にJSを使ったデモを埋め込んで実行させられるところです。
以下のIssueで紹介されてました。

https://github.com/vuejs/vitepress/discussions/2183

以下のようなコードを書きます。
mdファイル内に複雑なTypescriptを書くのはよくないので、ベルファイルに分けています。

```md:docs/introduction/what-is-react-dropzone-vv.md
# What is react-dropzone-vv

Simple React hook to create a drag-and-drop zone for files.
It is simple yet user-customizable.

A similar Package, [react-dropzone](https://github.com/react-dropzone/react-dropzone), is well known.
However, as of 2024, it has been out of date for about two years.
So I did not use react-dropzone for our own products, and used components I created myself. The created component is published as react-dropzone-vv.

react-dropzone-vv is heavily influenced by react-dropzone, but instead of Forking the repository, we rewrote it from scratch.
The purpose of react-dropzone-vv is to provide a simple and easy-to-use HTML5-compliant drag-and-drop zone for files.

# demo

<div ref="el" />

<script setup>
import { createElement } from 'react'
import { createRoot } from 'react-dom/client'
import { ref, onMounted } from 'vue'
import { Introduction } from './Introduction'

const el = ref()
onMounted(() => {
  const root = createRoot(el.value)
  root.render(createElement(Introduction, {}, null))
})
</script>

```

```tsx:docs/introduction/Introduction.tsx
import { FC, useState } from "react"
import {
  useReactDropzoneVV,
  ReactDropzoneVV,
  RejectedClassifiedFile,
} from "../../lib/index"

export const Introduction: FC = () => {
  const [acceptedFiles, setAcceptedFiles] = useState<File[]>([])
  const [fileRejections, setFileRejections] = useState<
    RejectedClassifiedFile[]
  >([])

  const reactDropzoneVV = useReactDropzoneVV({
    accept: "image/*",
    onSelect: async (props) => {
      setAcceptedFiles(props.acceptedFiles)
      setFileRejections(props.fileRejections)
    },
    onError: (e) => {
      console.log(e)
    },
  })

  return (
    <section style={{ border: "solid", padding: "1rem" }}>
      <ReactDropzoneVV
        reactDropzoneVV={reactDropzoneVV}
        style={{
          padding: "2rem",
          border: "dashed",
          backgroundColor: reactDropzoneVV.isDragging ? "#737373" : "#404040",
        }}
      >
        <p>Drag & drop some files here, or click to select files</p>
        <p>{'(Allowed mime type is "image/*"")'}</p>
      </ReactDropzoneVV>

      <div>acceptedFiles</div>
      <ul>
        {acceptedFiles.map((acceptedFile, index) => (
          <li key={index}>{acceptedFile.name}</li>
        ))}
      </ul>
      <div>fileRejections</div>
      <ul>
        {fileRejections.map((fileRejection, index) => (
          <span key={index}>
            <li>{fileRejection.file.name}</li>
            <ul>
              <li>{fileRejection.rejectedCode}</li>
            </ul>
          </span>
        ))}
      </ul>
    </section>
  )
}

```

以下のような画面を表示できます。



![](https://storage-noh-production.noh.ink/public/users/2goNuJNOwlWdiNM2FK20SARNFYq2/markdownImages/7tujudDi2CaM2d4YNat3/origin.webp)

こちらから動かすこともできます。

https://react-dropzone-vv.yosidev.com/introduction/what-is-react-dropzone-vv.html



# lib/のコードをdocs/にimportするときにエイリアスを使う

```tsx
import {
  useReactDropzoneVV,
  ReactDropzoneVV,
  RejectedClassifiedFile,
} from "../../lib/index"
```

の部分で毎回相対パスを書くのは面倒なのでエイリアスを設定しましょう。

tsconfig.jsonとvite.config.tsにエイリアスの設定があることを確認してください。

```json:tsconfig.json
    "baseUrl": ".",
    "paths": {
      "@lib/*": ["./lib/*"]
    }
```

```ts:vite.config.ts
    resolve: {
      alias: [{ find: "@lib", replacement: "/lib" }],
    },
```

そしてtsconfig.jsonの`include`に./docsを追加します。

```diff:tsconfig.json
- "include": ["./lib", "./src"]
+ "include": ["./lib", "./src", "./docs"]
```

さらにdocs/.vitepress/config.tsにもaliasの設定を追加します。

```ts:docs/.vitepress/config.ts
import { defineConfig } from "vitepress"

// https://vitepress.dev/reference/site-config
export default defineConfig({
  title: "react-dropzone-vv",
  description: "...",
  themeConfig: {
    ...
  },
  vite: {
    resolve: {
      alias: [{ find: "@lib", replacement: "/../lib" }],
    },
  },
})

```

これで以下のようにエイリアスインポートできるようになりました。

```tsx
import {
  useReactDropzoneVV,
  ReactDropzoneVV,
  RejectedClassifiedFile,
} from "@lib/index"
```

# ドキュメントのデプロイとホスティング

これに関しては選択肢がたくさんあるので紹介程度に留めます。

ホスティング先の候補としてはおすすめ順にGithub Pages, Cloudflare Pages, Netlifyです。mainブランチにマージされた時に自動的にデプロイしてもいいですが、僕はホスティングしてるサービスの管理画面から手動でデプロイするように設定しています（デプロイ頻度が低いので）。

docs/.vitepress/dist のファイルがアップロードされるように設定するだけなので難しくないと思います。


# 最後に

これで解説は終わりです。

この記事を読んでいるということはパッケージを作っていると思います。

ぜひ頑張ってください！

あと、react-dropzone-vvをよろしく。

https://github.com/yosipy/react-dropzone-vv

Blogs & Mini Blogs