create-ampless 1.0.0-alpha.78 → 1.0.0-alpha.80

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -15,8 +15,49 @@
15
15
 
16
16
  ---
17
17
 
18
+ ## 0. テーマとプラグインの境界線
19
+
20
+ ampless はテーマとプラグインの両方を提供します。用途に合ったものを選ぶことで、未来の自分や他のサイト作者が迷わずコードを見つけられます。
21
+
22
+ | やりたいこと | テーマを使う | プラグインを使う |
23
+ |---|---|---|
24
+ | レイアウト・タイポグラフィ・配色・ルート単位の UI | ✓ | |
25
+ | home / post / tag ページのカスタムコンポーネント | ✓ | |
26
+ | 非開発者が admin から編集できる設定 | | ✓ (`adminSettings`) |
27
+ | コンテンツイベント後のバックグラウンド処理(RSS・検索インデックス・webhook) | | ✓ (`eventHooks`) |
28
+ | 信頼できる副作用(S3 書き込み・外部 API 送信) | | ✓ (`writePublicAsset` + `trusted`) |
29
+ | テーマに依存しない `<head>` / `<body>` 注入(アナリティクス・同意バナー) | | ✓ (`publicHead` / `publicBodyEnd`) |
30
+ | 投稿単位の機械可読メタデータ(JSON-LD 等) | | ✓ (`schema` via `publicBodyForPost`) |
31
+ | 複数の ampless サイトで共有したいコード | | ✓ (npm パッケージとして公開) |
32
+
33
+ 判断の目安:
34
+
35
+ - テーマ = **ページの見た目**。render 時は読み取り専用。
36
+ - プラグイン = **render を超えて起こること**: admin 編集可能な設定、バックグラウンド処理、テーマ非依存の注入、機械可読メタデータ、サイト間の再利用。
37
+
38
+ 新しいプラグイン作者がよく踏む 2 つの境界線:
39
+
40
+ - **ストレージ / DynamoDB / 外部 API 書き込みはプラグインに置く**。テーマは読み取り専用です。
41
+ - **admin が `/admin/plugins` からオン・オフしたい機能はプラグインに置く**。表面上の効果が純粋に見た目だけであっても同様です。テーマも独自の設定を持てますが、それはテーマ表示設定であり、サイト運用設定ではありません。
42
+
43
+ 境界線上に本当に乗っている機能については [`docs/architecture/08-plugin-architecture.md`](https://github.com/heavymoons/ampless/blob/main/docs/architecture/08-plugin-architecture.md) で詳しく議論しています。
44
+
45
+ ---
46
+
18
47
  ## 1. プラグインで何ができるか
19
48
 
49
+ ampless プラグインは 3 つのいずれかの場所に書きます — コードをどのくらい広く共有したいかに応じて選んでください:
50
+
51
+ | どこに置くか | 使い時 | 置き場所 |
52
+ |---|---|---|
53
+ | **ファーストパーティ** | ampless コアへの全員向け貢献 | ampless モノレポ内の `packages/plugin-*/` |
54
+ | **サイトローカル** | サイト固有のカスタマイズ、個別 publish 不要 | サイトリポジトリ内の `plugins/<name>/` |
55
+ | **外部 npm パッケージ** | 他のサイトと共有したい、`npm publish` 想定 | スタンドアロンリポジトリ (`@scope/ampless-plugin-foo`) |
56
+
57
+ 3 つの形式はすべて同じ `definePlugin({...})` ファクトリを呼び出し、同じサーフェスを使います。違いはパッケージング・配布方法、および静的 `package.json#amplessPlugin` マニフェストが有効にするインストール時バリデーションのオプトインです(§3 参照)。
58
+
59
+ §14 には一行のスキャフォールドコマンド (`npx create-ampless plugin <name>`) があり、後者 2 つのどちらにも即使えるボイラープレートを生成します。
60
+
20
61
  ampless プラグインは `AmplessPlugin` オブジェクトを返す TypeScript モジュールです。以下のうち 1 つ以上のサーフェスにフックします:
21
62
 
22
63
  | サーフェス | 実行場所 | 同期 / 非同期 | Phase |
@@ -30,30 +71,65 @@ ampless プラグインは `AmplessPlugin` オブジェクトを返す TypeScrip
30
71
  | `hooks` | trust_level に応じた processor Lambda | 非同期、SQS イベントで起動 | 既存 |
31
72
  | `settings.public` | `/admin/plugins` フォーム | 宣言的なマニフェスト | 2 |
32
73
 
33
- **現時点でできないこと** (将来の privileged 層実装に依存、ロードマップ参照):
34
-
35
- - 任意の `ReactNode` をページに注入 — descriptor 変種のみ許可
36
- - 公開 Next.js プロセス内で TCP ソケットを開く。trusted Lambda も外向き HTTP のみ
37
- - admin ルート / server ルート / コンテンツフィールドの追加 — Phase 6b 予約
38
- - secret の読み書き。`secretSettings` capability Phase 6a 予約
74
+ 後続フェーズに残してある surface もいくつかあって、現状の `definePlugin`
75
+ では形にできません:
76
+
77
+ - **任意の `ReactNode` のページ注入**。同期描画 surface (`publicHead` /
78
+ `publicBodyEnd` / `publicBodyForPost`) descriptor 変種を返すだけ。
79
+ descriptor validator**runtime が描画する HTML 出力の安全境界**
80
+ であって、プラグイン本体のコードを縛る JS sandbox ではない (プラグインは
81
+ 普通の TypeScript としてサイトと同一の Node プロセス内で動く)
82
+ - **同期描画 surface 内でのネットワーク**。これらの surface は宣言的な
83
+ 出力を返す設計で、Promise を受け取らないし async result path も無い。
84
+ `publicHead` の中で `await fetch(...)` を書くと SSR が無期限ブロックする
85
+ (デッドラインを返す手段がない)。外向き HTTP が必要な処理は trusted
86
+ Lambda (`hooks`) でやる
87
+ - **admin ルート / server ルート / コンテンツフィールドの追加** —
88
+ Phase 6b 予約
89
+ - **secret の読み書き**。`secretSettings` capability は Phase 6a 予約。
90
+ `settings.public` に credential を置かないこと
39
91
 
40
92
  ---
41
93
 
42
94
  ## 2. 最小ファイル構成
43
95
 
44
- プラグインは小さな npm パッケージとして公開しても、サイトのモノレポ内に置いてもよいです。on-disk の構成はどちらでも同じ:
96
+ プラグインを作る最速の方法はスキャフォールドです:
97
+
98
+ ```bash
99
+ # サイトローカル (現在の ampless サイトに plugins/<name>/index.ts を生成)
100
+ npx create-ampless@latest plugin my-thing
45
101
 
102
+ # スタンドアロン npm パッケージ (`npm publish` 向けの ./<name>/ を生成)
103
+ npx create-ampless@latest plugin @myscope/ampless-plugin-my-thing --standalone
46
104
  ```
47
- my-plugin/
105
+
106
+ 全体の手順は §14 を参照してください。このセクションの残りでは生成されるファイルの意味を説明します — 手書きしたい場合はここを読めば把握できます。
107
+
108
+ ### サイトローカル
109
+
110
+ ```
111
+ plugins/
112
+ my-thing/
113
+ index.ts # ファクトリ関数のみ。これがプラグインの全体
114
+ ```
115
+
116
+ サイトの `package.json` / `tsconfig.json` がコンパイルを担うため、追加で ship するものはありません。`cms.config.ts` から相対 import で登録します。
117
+
118
+ ### スタンドアロン npm パッケージ
119
+
120
+ ```
121
+ ampless-plugin-my-thing/
48
122
  package.json
49
123
  tsconfig.json
50
124
  tsup.config.ts
125
+ README.md
126
+ CHANGELOG.md
51
127
  src/
52
128
  index.ts
53
129
  index.test.ts
54
130
  ```
55
131
 
56
- 本レポ内の `packages/plugin-rss/` と `packages/plugin-analytics-ga4/` が動作する参考実装です。
132
+ 本レポ内の `packages/plugin-rss/` と `packages/plugin-analytics-ga4/` が動作するファーストパーティの参考実装です — スタンドアロンスキャフォールドはこれらのレイアウトを踏襲します。
57
133
 
58
134
  最小の `src/index.ts`:
59
135
 
@@ -93,6 +169,7 @@ export default defineConfig({
93
169
  ```ts
94
170
  interface AmplessPlugin {
95
171
  name: string // パッケージ風の識別子。例: 'analytics-ga4'
172
+ packageName?: string // インストール時のクロスチェック用 npm パッケージ名
96
173
  apiVersion: 1 // 契約が変わるときだけ bump
97
174
  trust_level: 'untrusted' | 'trusted' | 'privileged'
98
175
  instanceId?: string // 複数インストール時の namespace
@@ -132,6 +209,67 @@ analyticsGa4Plugin({ instanceId: 'product' })
132
209
 
133
210
  `/admin/plugins` のパネル見出し。単一ロケールのプラグインなら平文の文字列で十分。`{ en: 'GA4', ja: 'GA4' }` 形式の per-locale map にすると admin のアクティブロケールに応じて読み分けられます。
134
211
 
212
+ ### `packageName`
213
+
214
+ 省略可能。設定すると、runtime は起動時に `<packageName>/package.json` を解決し、そこにある静的な `amplessPlugin` ブロックをファクトリの戻り値とクロスチェックします。これにより、runtime で初めて気づく(あるいは永遠に気づかない)インストール時のミスを検出できます — capability の不一致はクラッシュせず、該当サーフェスが静かにスキップされるだけです。
215
+
216
+ スタンドアロンプラグインでは、`package.json#name` で宣言している npm パッケージ名をここに設定します:
217
+
218
+ ```ts
219
+ return definePlugin({
220
+ name: 'site-verification',
221
+ packageName: '@ishinao/ampless-plugin-site-verification',
222
+ apiVersion: 1,
223
+ // ...
224
+ })
225
+ ```
226
+
227
+ サイトローカルプラグインは不要です — 未設定のままにするとクロスチェックはスキップされます(Phase 5 より前のプラグインとの後方互換)。
228
+
229
+ ### `package.json` の静的マニフェスト(スタンドアロンプラグインのみ)
230
+
231
+ クロスチェックが静的マニフェストを見つけるには、公開パッケージに 2 つの条件が必要です:
232
+
233
+ 1. `package.json#amplessPlugin` がファクトリの戻り値と同じフィールドを宣言している:
234
+
235
+ ```json
236
+ "amplessPlugin": {
237
+ "apiVersion": 1,
238
+ "name": "site-verification",
239
+ "trustLevel": "untrusted",
240
+ "capabilities": ["publicHead", "adminSettings"],
241
+ "displayName": { "en": "Site verification", "ja": "サイト所有権確認" }
242
+ }
243
+ ```
244
+
245
+ 2. `package.json#exports` が `./package.json` を明示的に公開している:
246
+
247
+ ```json
248
+ "exports": {
249
+ ".": {
250
+ "import": "./dist/index.js",
251
+ "types": "./dist/index.d.ts"
252
+ },
253
+ "./package.json": "./package.json"
254
+ }
255
+ ```
256
+
257
+ これがないと、Node のパッケージエクスポートの制約により `import.meta.resolve('<pkg>/package.json')` が `ERR_PACKAGE_PATH_NOT_EXPORTED` で拒否され、runtime はクロスチェックを静かにスキップします(プラグインは動きますが、インストール時ガードは機能しません)。
258
+
259
+ `create-ampless plugin --standalone` スキャフォールドは両方を正しく生成します。また `package.json#keywords` に `"ampless-plugin"` を加えておくことをお勧めします — npm 検索で ampless プラグインを探す際の慣例です。
260
+
261
+ runtime がチェックする内容:
262
+
263
+ | フィールド | 不一致時の動作 |
264
+ |---|---|
265
+ | `apiVersion`(ファクトリ vs マニフェスト) | 起動時に **throws** |
266
+ | `apiVersion`(runtime がサポートするバージョンより新しい) | 起動時に **throws** |
267
+ | `name` | dev で warn |
268
+ | `trustLevel` | dev で warn |
269
+ | `capabilities`(集合比較) | dev で warn |
270
+
271
+ 起動を中断するのは 2 つの `apiVersion` ケースのみです — これは runtime が対応していない ampless API でビルドされたプラグインのロードを防ぎます。その他はすべて開発者向けの警告であり、runtime のブロックではありません。
272
+
135
273
  ---
136
274
 
137
275
  ## 4. `trust_level` の選び方
@@ -156,7 +294,13 @@ trust level がズレているプラグインは「権限不足で sliently fail
156
294
 
157
295
  ## 5. 同期サーフェス
158
296
 
159
- **公開 Next.js プロセス** (サイト訪問者のリクエストスレッド) 内で実行されます。AWS に対しては純 (IAM・ネットワーク無し) で、同期実行です。
297
+ **公開 Next.js プロセス** (サイト訪問者のリクエストスレッド) 内で同期実行
298
+ されます。これらの surface はネットワーク I/O を意図して設計していません。
299
+ async result path が無いので `publicHead` 内で `await fetch(...)` すると
300
+ SSR がデッドラインなしでブロックします。ネットワーク呼び出しが必要な副作用
301
+ は `hooks` (trusted Lambda、async) でやってください。公開プロセス内の
302
+ プラグインコードは公開ページ用の IAM ロールで動きます — 特別な AWS 権限は
303
+ ありません。
160
304
 
161
305
  | サーフェス | 戻り値 | 用途 |
162
306
  |---|---|---|
@@ -181,7 +325,14 @@ trust level がズレているプラグインは「権限不足で sliently fail
181
325
 
182
326
  ## 6. Descriptor リファレンス
183
327
 
184
- `publicHead` と `publicBodyEnd` は **descriptor オブジェクト** を返します。`ReactNode` ではありません。runtime が validation してから React 要素を組み立てます。これが untrusted コードを公開描画パスで動かすための安全境界です。
328
+ `publicHead` と `publicBodyEnd` は **descriptor オブジェクト** を返します。
329
+ `ReactNode` ではありません。runtime が validation (URL scheme denylist /
330
+ attrs allowlist / id dedup) してから React 要素を組み立てます。これは
331
+ プラグインが寄与できる **HTML 出力** の安全境界であって、プラグイン本体の
332
+ コード実行を縛るものではない、という点に注意 — プラグインは普通の
333
+ TypeScript としてサイトと同一の Node プロセスで動きます。descriptor
334
+ パイプラインは、JS sandbox に頼らずに公開ページの面を狭く / 監査可能に
335
+ 保つための仕組みです。
185
336
 
186
337
  ### 共通の variant
187
338
 
@@ -319,6 +470,26 @@ export default function schemaJsonldPlugin() {
319
470
 
320
471
  テーマの `pages/post.tsx` が `ampless.publicBodyForPost(post)` を呼び、返された descriptor を描画します。runtime は自動 escape した body を持つ `<script type="application/ld+json">` 要素をページに挿入します。
321
472
 
473
+ ### クライアントサイドの DOM 操作はしない
474
+
475
+ `publicHead` または `publicBodyEnd` から返したインラインスクリプトは、React がページを hydrate する前、HTML のパース中に実行されます。**React が管理するサブツリー内の見える DOM を操作してはいけません** — hydration が走ると React は仮想 DOM と合わないツリーを検出し、`Hydration failed because the server rendered HTML didn't match the client` エラーを投げてサブツリーをゼロから再生成します。挿入したノードは消えてしまいます。
476
+
477
+ React 19 はさらに、クライアントコンポーネントのレンダー中に出会った `<script>` タグの実行を拒否するため、`document.body.append(myNewElement)` のようなスクリプトはそもそも発火しないことがあります。
478
+
479
+ **安全なパターン**:
480
+
481
+ - **グローバル状態 / 非 DOM の副作用**: `window.dataLayer` への push、設定オブジェクトのセット、アナリティクス SDK のインスタンス化。`@ampless/plugin-analytics-ga4`・`@ampless/plugin-gtm`・`@ampless/plugin-plausible` はこの方法を使っています。
482
+ - **外部ウィジェットローダー**: 自前の独立したコンテナを管理するサードパーティスクリプトの読み込み(Crisp・Intercom・Drift など)。ウィジェットの shadow DOM / fixed-position オーバーレイは React のツリーの外にあり、hydration と競合しません。
483
+ - **SSR 専用の descriptor**: `meta` / `link` / `noscript`(`publicBodyEnd` では `iframe` も)を返す — runtime がサーバーサイドで描画するため、最初から React の仮想 DOM の一部になります。
484
+
485
+ **避けるべきパターン**:
486
+
487
+ - `document.createElement('div')` + `document.body.append(...)`
488
+ - テーマが描画した要素のクラス / 属性 / テキストコンテンツの変更
489
+ - クライアントサイドで `#post-body` のような要素を読み取って投稿単位の HTML を挿入する — 現在 `publicHead`-for-post に相当するサーフェスはなく、サーバーレンダリング済みのサブツリーをクライアントサイドで書き換えると hydration と競合します
490
+
491
+ 投稿単位の見える出力には、`publicBodyForPost` 経由で JSON-LD を返す(§6 の `PublicPostBodyDescriptor` 参照)か、テーマ自身のテンプレートを使ってください。サーバーサイドでの投稿単位 HTML 注入はロードマップに載っています。
492
+
322
493
  ---
323
494
 
324
495
  ## 7. 非同期イベントフック
@@ -591,7 +762,82 @@ it('admin が空文字保存した場合は空配列', () => {
591
762
 
592
763
  ---
593
764
 
594
- ## 14. 質問先
765
+ ## 14. クイックスタート: `create-ampless` でスキャフォールド
766
+
767
+ アイデアから動くプラグインへの最速ルートとして、`create-ampless` CLI には `plugin <name>` サブコマンドが用意されています:
768
+
769
+ ```bash
770
+ # サイトローカル: 現在の ampless サイトのルートで実行
771
+ # plugins/<name>/index.ts を生成する
772
+ npx create-ampless@latest plugin my-thing \
773
+ --trust-level untrusted \
774
+ --capabilities publicHead,adminSettings
775
+
776
+ # スタンドアロン npm パッケージ: ./<dir>/ を生成
777
+ # package.json / tsconfig.json / tsup.config.ts / README + .ja /
778
+ # CHANGELOG / .gitignore / src/index.ts + src/index.test.ts を含む
779
+ # 新しいパッケージディレクトリを置きたい場所で実行する
780
+ npx create-ampless@latest plugin @myscope/ampless-plugin-thing \
781
+ --standalone \
782
+ --trust-level untrusted \
783
+ --capabilities publicHead,adminSettings \
784
+ --description "このプラグインが何をするか"
785
+ ```
786
+
787
+ スタンドアロンスキャフォールドには Phase 5 のクロスチェックに必要なものがすべて含まれます: `package.json#amplessPlugin`、`./package.json` サブパスエクスポート、`packageName` ファクトリフィールド、`ampless-plugin` 検索キーワード、そして `pnpm install && pnpm test && pnpm build` が生成直後にクリーンに通る最小の vitest サンプル。
788
+
789
+ どちらのモードも、フラグなしの位置引数呼び出し (`npx create-ampless@latest plugin`) で @clack のプロンプト UI を使ったインタラクティブモードに切り替えられます。
790
+
791
+ ### スタンドアロンプラグインの公開
792
+
793
+ ```bash
794
+ cd ampless-plugin-thing
795
+ pnpm install
796
+ pnpm test
797
+ pnpm build
798
+ pnpm publish --access public --tag alpha
799
+ ```
800
+
801
+ スコープ付き名前 (`@scope/...`) には `--access public` が必須です。`--tag alpha` は現在の ampless プレリリースサイクルに合わせています — 安定 major に達したら外してください。
802
+
803
+ `npm publish` が返った直後に `npm install <pkg>@alpha` で 404 が出ることがあります(CDN とレジストリレプリカの伝播遅延)。その場合は 1〜2 分待ってリトライしてください — `npm view <pkg>@alpha version` がレジストリで見えていることは必要条件ですが十分条件ではありません。
804
+
805
+ ### パッケージの命名
806
+
807
+ npm の慣例として、スコープと `ampless-plugin-` プレフィックスを除いた短い識別子が `AmplessPlugin.name` になります:
808
+
809
+ | npm パッケージ | `AmplessPlugin.name` |
810
+ |---|---|
811
+ | `@ampless/plugin-gtm` | `gtm` |
812
+ | `@scope/ampless-plugin-clarity` | `clarity` |
813
+ | `ampless-plugin-readme-toc` | `readme-toc` |
814
+ | `weird-name-no-prefix` | `weird-name-no-prefix` |
815
+
816
+ スキャフォールドはこのストリッピングを自動で行います。スキャフォールドを使わない場合も同じマッピングで手書きしてください。パッケージの静的マニフェストとファクトリで `name` が一致しない場合はインストール時クロスチェックが警告します。
817
+
818
+ ### サイトローカルの後作業
819
+
820
+ サイトローカルのスキャフォールド後:
821
+
822
+ ```ts
823
+ // cms.config.ts
824
+ import myThingPlugin from './plugins/my-thing'
825
+
826
+ export default defineConfig({
827
+ // ...
828
+ plugins: [
829
+ myThingPlugin(),
830
+ ],
831
+ })
832
+ ```
833
+
834
+ スキャフォールドの最後にこのスニペットが表示されます — `cms.config.ts` にコピーしてプラグインを有効化してください。
835
+
836
+ `update-ampless` は `plugins/` ディレクトリを決して変更しません(PROTECTED 扱い)。ampless のアップグレードをまたいでも安全に残ります。
837
+
838
+ ---
839
+
840
+ ## 15. 質問先
595
841
 
596
842
  - アーキテクチャ / 設計の質問 → [`docs/architecture/08-plugin-architecture.ja.md`](https://github.com/heavymoons/ampless/blob/main/docs/architecture/08-plugin-architecture.ja.md)
597
843
  - ファーストパーティプラグインの bug → `heavymoons/ampless` にプラグインの package 名つきで issue