@forumone/create-throughline 1.0.2-pr-282-bf0a261 → 1.1.0-pr-281-cab5a91
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.
- package/CHANGELOG.md +1 -1
- package/README.md +11 -15
- package/dist/templates/base/.env.example +5 -6
- package/dist/templates/base/CLAUDE.md +5 -10
- package/dist/templates/base/README.md +3 -4
- package/dist/templates/with-reference-ds/design-system/README.md +1 -1
- package/dist/templates/without-reference-ds/design-system/README.md +1 -1
- package/dist/versions.json +2 -2
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# @forumone/create-throughline
|
|
2
2
|
|
|
3
|
-
Scaffolder for new Throughline projects
|
|
3
|
+
Scaffolder for new Throughline projects (Payload CMS + MCP servers + Inngest workflows).
|
|
4
4
|
|
|
5
5
|
## Usage
|
|
6
6
|
|
|
@@ -14,32 +14,28 @@ Or with npm:
|
|
|
14
14
|
npm create @forumone/throughline@latest my-client-site
|
|
15
15
|
```
|
|
16
16
|
|
|
17
|
-
The scaffolder asks a small set of questions, then generates a
|
|
18
|
-
with Payload,
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
content model with your own.
|
|
17
|
+
The scaffolder asks a small set of questions, then generates a ready-to-run
|
|
18
|
+
pnpm monorepo with Payload, all Throughline plugins, and an Inngest endpoint
|
|
19
|
+
already wired. After scaffolding you'll need to fill in environment variables,
|
|
20
|
+
implement client-specific resolvers (users, groups, approvers), and replace
|
|
21
|
+
the example content model with your own.
|
|
23
22
|
|
|
24
23
|
## What you get
|
|
25
24
|
|
|
26
25
|
```
|
|
27
26
|
my-client-site/
|
|
28
27
|
├── apps/
|
|
29
|
-
│ └── web/ # Next.js + Payload
|
|
30
|
-
├──
|
|
31
|
-
├──
|
|
32
|
-
├──
|
|
33
|
-
|
|
28
|
+
│ └── web/ # Next.js + Payload with all plugins wired
|
|
29
|
+
├── packages/
|
|
30
|
+
│ ├── design-system/ # Reference DS (or placeholder for your own)
|
|
31
|
+
│ ├── content/ # Client-specific collections & blocks
|
|
32
|
+
│ └── brand/ # Brand tokens + email theme
|
|
34
33
|
├── .env.example
|
|
35
|
-
├── CLAUDE.md
|
|
36
34
|
├── pnpm-workspace.yaml
|
|
37
35
|
├── turbo.json
|
|
38
36
|
└── README.md
|
|
39
37
|
```
|
|
40
38
|
|
|
41
|
-
The full list is in the [reference](https://github.com/forumone/throughline/blob/main/docs/reference/create-throughline.md).
|
|
42
|
-
|
|
43
39
|
## After scaffolding
|
|
44
40
|
|
|
45
41
|
Read the generated `README.md` for full setup instructions. Expect 1–2 hours
|
|
@@ -35,9 +35,9 @@ APPROVAL_TOKEN_SECRET=
|
|
|
35
35
|
|
|
36
36
|
# --- MCP ---
|
|
37
37
|
# No keys here. Every Throughline tool is served on one /api/mcp by
|
|
38
|
-
# @payloadcms/plugin-mcp; create a key in the admin under MCP ->
|
|
39
|
-
# give it to your MCP client, not to this file. Scheduled
|
|
40
|
-
# process and need no key either.
|
|
38
|
+
# @payloadcms/plugin-mcp; create a key in the admin under MCP -> Payload MCP
|
|
39
|
+
# API Keys and give it to your MCP client, not to this file. Scheduled
|
|
40
|
+
# publishes run in process and need no key either.
|
|
41
41
|
|
|
42
42
|
# --- Optional: error reporting ---
|
|
43
43
|
# Where unhandled request errors, workflows that ran out of retries and failing
|
|
@@ -48,7 +48,6 @@ APPROVAL_TOKEN_SECRET=
|
|
|
48
48
|
ERROR_WEBHOOK_URL=
|
|
49
49
|
|
|
50
50
|
# --- Optional: storage ---
|
|
51
|
-
#
|
|
52
|
-
#
|
|
53
|
-
# @payloadcms/storage-vercel-blob to deploy on Vercel.
|
|
51
|
+
# Vercel Blob token if deploying to Vercel; remove this and the storage
|
|
52
|
+
# adapter from payload.config.ts if you're using a different provider.
|
|
54
53
|
BLOB_READ_WRITE_TOKEN=
|
|
@@ -21,14 +21,10 @@ pnpm install --frozen-lockfile \
|
|
|
21
21
|
&& pnpm typecheck && pnpm lint \
|
|
22
22
|
&& pnpm check:instances && pnpm check:tested && pnpm check:migrations \
|
|
23
23
|
&& pnpm validate \
|
|
24
|
-
&& pnpm --filter ./design-system run --if-present build \
|
|
25
24
|
&& bash .github/scripts/check-generated.sh \
|
|
26
25
|
&& pnpm test
|
|
27
26
|
```
|
|
28
27
|
|
|
29
|
-
`fast` then runs `pnpm check:audit`, which reports advisories without failing
|
|
30
|
-
the job.
|
|
31
|
-
|
|
32
28
|
`--frozen-lockfile` leads because a lockfile missing an entry passes every
|
|
33
29
|
other gate locally and fails in CI. `check-generated.sh` needs the environment
|
|
34
30
|
`payload.config.ts` validates; the placeholders at the top of
|
|
@@ -79,8 +75,8 @@ and demands `--confirm` before overwriting.
|
|
|
79
75
|
|
|
80
76
|
## The design system reaches the CMS through its manifest
|
|
81
77
|
|
|
82
|
-
`payload.config.ts` hands the design system's manifest to
|
|
83
|
-
|
|
78
|
+
`payload.config.ts` hands the design system's manifest to `componentsPlugin`,
|
|
79
|
+
and that manifest is how the CMS knows which components exist and how they may
|
|
84
80
|
be composed. It is built from a `<Name>.contract.ts` beside every component.
|
|
85
81
|
{{#if useReferenceDs}}
|
|
86
82
|
- **A new component needs a contract.** `build:manifest` refuses a component
|
|
@@ -90,9 +86,8 @@ be composed. It is built from a `<Name>.contract.ts` beside every component.
|
|
|
90
86
|
that is not there.
|
|
91
87
|
{{else}}
|
|
92
88
|
The design system here is a placeholder. When you build it, give every
|
|
93
|
-
component a contract, publish a manifest, and point `
|
|
94
|
-
|
|
95
|
-
Throughline repository.
|
|
89
|
+
component a contract, publish a manifest, and point `componentsPlugin` at it —
|
|
90
|
+
see `@forumone/throughline-design-system` in the Throughline repository.
|
|
96
91
|
{{/if}}
|
|
97
92
|
## Tests
|
|
98
93
|
|
|
@@ -106,7 +101,7 @@ refused. A new collection fails it until you add it to a bucket. Decide which,
|
|
|
106
101
|
and don't open a collection to anonymous reads to make the test pass. More good
|
|
107
102
|
first tests need no database: field validations, and hooks as functions.
|
|
108
103
|
|
|
109
|
-
`pnpm
|
|
104
|
+
`pnpm test:smoke` runs the Playwright smoke pack in `e2e/` against
|
|
110
105
|
`next start`, so build first, or against a deployed site when `E2E_BASE_URL`
|
|
111
106
|
is set. Every check is a GET. CI runs it in `verify`, after the production
|
|
112
107
|
build. Add routes to `e2e/site.ts` as the site gains them.
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Generated by [`@forumone/create-throughline`](https://github.com/forumone/throughline/tree/main/packages/create-throughline).
|
|
4
4
|
|
|
5
|
-
This is a Throughline project: a Payload CMS application with the Throughline suite
|
|
5
|
+
This is a Throughline project: a Payload CMS application wired with the Throughline plugin suite (audit, components, publishing, approvals, audit-query, integrations, email) plus an Inngest endpoint that runs the workflow functions.
|
|
6
6
|
|
|
7
7
|
## Prerequisites
|
|
8
8
|
|
|
@@ -21,8 +21,7 @@ pnpm install
|
|
|
21
21
|
# 2. Copy the env template
|
|
22
22
|
cp .env.example apps/web/.env.local # apps/web: `next dev` reads env files from there
|
|
23
23
|
|
|
24
|
-
# 3. Generate
|
|
25
|
-
# once for each)
|
|
24
|
+
# 3. Generate secrets (run each three times for the three secret slots)
|
|
26
25
|
openssl rand -base64 48
|
|
27
26
|
|
|
28
27
|
# 4. Edit apps/web/.env.local and fill in:
|
|
@@ -57,7 +56,7 @@ pnpm dev
|
|
|
57
56
|
|
|
58
57
|
## After admin signup
|
|
59
58
|
|
|
60
|
-
1. In the Payload admin, open **MCP → API Keys** and create one key.
|
|
59
|
+
1. In the Payload admin, open **MCP → Payload MCP API Keys** and create one key. Pick a **User** — required; the key inherits that user's access control — tick **Enable API Key**, save, and copy the key. It is shown once, and it does not go in `.env.local`.
|
|
61
60
|
|
|
62
61
|
2. **Plug it into Claude (or your MCP client).** One endpoint carries every server's tools:
|
|
63
62
|
|
|
@@ -22,7 +22,7 @@ pnpm --filter "./design-system" validate # lint contracts + cross-check
|
|
|
22
22
|
pnpm --filter "./design-system" test # component tests (vitest + testing-library)
|
|
23
23
|
```
|
|
24
24
|
|
|
25
|
-
The web app imports `./manifest` (the built `dist/manifest.json`) and
|
|
25
|
+
The web app imports `./manifest` (the built `dist/manifest.json`) and feeds it to the Components MCP server. The root `pnpm dev` builds the design system first so the manifest exists.
|
|
26
26
|
|
|
27
27
|
## Branding
|
|
28
28
|
|
|
@@ -17,4 +17,4 @@ pnpm --filter "./design-system" build-storybook # static Storybook
|
|
|
17
17
|
pnpm --filter "./design-system" typecheck
|
|
18
18
|
```
|
|
19
19
|
|
|
20
|
-
Point
|
|
20
|
+
Point the Components MCP server at your manifest in `apps/web/src/payload.config.ts` (`componentsPlugin({ manifest })`) once you generate one. For a worked starting point, re-scaffold with the reference design system.
|
package/dist/versions.json
CHANGED
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@forumone/create-throughline",
|
|
3
|
-
"version": "1.0
|
|
4
|
-
"description": "Scaffolder for new Throughline projects
|
|
3
|
+
"version": "1.1.0-pr-281-cab5a91",
|
|
4
|
+
"description": "Scaffolder for new Throughline projects (Payload CMS + MCP servers + Inngest workflows).",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
7
7
|
"create-throughline": "./dist/bin.js"
|