prisma-php 0.0.11 → 0.0.13
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/.github/copilot-instructions.md +21 -4
- package/dist/docs/authentication.md +10 -10
- package/dist/docs/backend-only.md +1 -1
- package/dist/docs/bootstrap-runtime.md +145 -0
- package/dist/docs/commands.md +161 -27
- package/dist/docs/components.md +1 -1
- package/dist/docs/fetching-data.md +1 -1
- package/dist/docs/get-started-ia.md +2 -0
- package/dist/docs/index.md +29 -7
- package/dist/docs/installation.md +9 -5
- package/dist/docs/layouts-and-pages.md +15 -9
- package/dist/docs/mcp.md +4 -0
- package/dist/docs/metadata-and-og-images.md +51 -43
- package/dist/docs/prisma-php-orm.md +19 -15
- package/dist/docs/project-structure.md +51 -5
- package/dist/docs/pulsepoint.md +10 -2
- package/dist/docs/route-handlers.md +2 -2
- package/dist/docs/swagger-docs.md +10 -2
- package/dist/docs/typescript.md +202 -0
- package/dist/docs/upgrading.md +12 -1
- package/dist/docs/websocket.md +4 -0
- package/package.json +1 -1
|
@@ -2,11 +2,22 @@
|
|
|
2
2
|
|
|
3
3
|
## Source Of Truth
|
|
4
4
|
|
|
5
|
-
-
|
|
6
|
-
- Read the matching doc in `dist/docs` before generating or editing framework-specific Prisma PHP code.
|
|
7
|
-
-
|
|
5
|
+
- For Prisma PHP applications, treat `node_modules/prisma-php/dist/docs/index.md` as the entry point for the installed framework version.
|
|
6
|
+
- Read the matching doc in `node_modules/prisma-php/dist/docs` before generating or editing framework-specific Prisma PHP code.
|
|
7
|
+
- Expect `AGENTS.md` in the project root and keep it aligned with the installed Prisma PHP docs contract.
|
|
8
|
+
- In the Prisma PHP package source repo, keep `AGENTS.md`, `.github/copilot-instructions.md`, and `dist/docs` aligned so the published docs remain correct after install.
|
|
9
|
+
- Do not assume installed consumer apps also ship a root `.github/copilot-instructions.md` unless the generator explicitly creates one.
|
|
8
10
|
- Keep every `dist/docs/*.md` page AI-discoverable on its own: the frontmatter description and opening section should clearly say when agents should read that file and which adjacent docs to consult next.
|
|
9
11
|
|
|
12
|
+
## Framework-Managed Package Scripts
|
|
13
|
+
|
|
14
|
+
- Prisma PHP can generate `package.json` scripts for BrowserSync, Tailwind, TypeScript, WebSocket, MCP, Swagger docs, and related helpers.
|
|
15
|
+
- Prefer `npm run dev` for ordinary local development and `npm run build` for ordinary production-style asset builds.
|
|
16
|
+
- Do not default to telling users to run `npm run tailwind`, `npm run tailwind:build`, `npm run ts:watch`, or `npm run ts:build` after routine file changes, because those are usually orchestrated through the generated top-level scripts.
|
|
17
|
+
- Use `npm run websocket` or `npm run mcp` only when isolating local runtime startup, debugging, or when the project's scripts show those services are not already covered by the normal development flow.
|
|
18
|
+
- Use `npm run create-swagger-docs` only when Swagger or OpenAPI output must be intentionally generated or refreshed.
|
|
19
|
+
- When package-script behavior matters, read `dist/docs/commands.md` first and inspect the actual `package.json` in the target project before assuming which scripts exist.
|
|
20
|
+
|
|
10
21
|
## Route File Conventions
|
|
11
22
|
|
|
12
23
|
- For PulsePoint-aware `index.php` and nested `layout.php`, keep file order as PHP first, then one parent HTML element; keep the PulsePoint `<script>` as the last child inside that same root element.
|
|
@@ -17,26 +28,32 @@
|
|
|
17
28
|
## Component Boundary Rules
|
|
18
29
|
|
|
19
30
|
- Distinguish PHPX class components from `ImportComponent` partials.
|
|
20
|
-
- `ImportComponent` partials must output exactly one root element because Prisma PHP
|
|
31
|
+
- `ImportComponent` partials must output exactly one root element because Prisma PHP uses that root as the imported component boundary and serializes props there.
|
|
21
32
|
- Do not manually add `pp-component` inside `ImportComponent` partial source; Prisma PHP injects it there. For normal PulsePoint-aware route files, add `pp-component` to the single root element yourself.
|
|
22
33
|
|
|
23
34
|
## Relevant Docs
|
|
24
35
|
|
|
25
36
|
- Project structure and feature placement: `dist/docs/project-structure.md`
|
|
26
37
|
- CLI project creation and update commands: `dist/docs/commands.md`
|
|
38
|
+
- First-time project installation and local setup: `dist/docs/installation.md`
|
|
39
|
+
- Existing-project upgrades and feature refreshes: `dist/docs/upgrading.md`
|
|
40
|
+
- TypeScript frontend tooling, the `typescript` flag, and `ts/main.ts` registration: `dist/docs/typescript.md`
|
|
27
41
|
- Backend-only API usage and `backendOnly`: `dist/docs/backend-only.md`
|
|
28
42
|
- Route and layout structure: `dist/docs/layouts-and-pages.md`
|
|
29
43
|
- AI integration, provider-backed chat, streaming, and MCP boundary: `dist/docs/get-started-ia.md`
|
|
30
44
|
- Data loading, `#[Exposed]`, and SSE streaming: `dist/docs/fetching-data.md`
|
|
31
45
|
- PulsePoint runtime rules: `dist/docs/pulsepoint.md`
|
|
32
46
|
- Component and `ImportComponent` rules: `dist/docs/components.md`
|
|
47
|
+
- Cache behavior and `CacheHandler`: `dist/docs/caching.md`
|
|
33
48
|
- Validation rules: `dist/docs/validator.md`
|
|
49
|
+
- Prisma ORM schema, migrations, and generated PHP classes: `dist/docs/prisma-php-orm.md`
|
|
34
50
|
- Environment variables and `PP\Env` usage: `dist/docs/env.md`
|
|
35
51
|
- File uploads and file manager behavior: `dist/docs/file-manager.md`
|
|
36
52
|
- Email and SMTP workflows: `dist/docs/email.md`
|
|
37
53
|
- WebSocket and realtime behavior: `dist/docs/websocket.md`
|
|
38
54
|
- MCP server and tool rules: `dist/docs/mcp.md`
|
|
39
55
|
- Authentication: `dist/docs/authentication.md`
|
|
56
|
+
- Error handling, expected failures, and route error files: `dist/docs/error-handling.md`
|
|
40
57
|
- Metadata and icons: `dist/docs/metadata-and-og-images.md`
|
|
41
58
|
- API-style handlers and webhooks: `dist/docs/route-handlers.md`
|
|
42
59
|
- Swagger/OpenAPI generation and `swaggerDocs`: `dist/docs/swagger-docs.md`
|
|
@@ -33,7 +33,7 @@ Do not assume another framework’s auth abstractions apply directly.
|
|
|
33
33
|
|
|
34
34
|
## Read this doc when you need
|
|
35
35
|
|
|
36
|
-
- **route privacy defaults, `AuthConfig.php`, JWT session lifecycle, `Auth::signIn(...)`, `Auth::signOut(...)`, `refreshUserSession(...)`, route RBAC, or provider overview** → official `auth-get-started`
|
|
36
|
+
- **route privacy defaults, `AuthConfig.php`, JWT session lifecycle, `Auth::getInstance()->signIn(...)`, `Auth::getInstance()->signOut(...)`, `Auth::getInstance()->refreshUserSession(...)`, route RBAC, or provider overview** → official `auth-get-started`
|
|
37
37
|
- **email/password registration, login, password hashing, CSRF-aware credential flow, or user/role schema design** → official `credentials`
|
|
38
38
|
- **social login, provider credentials, callback route handling, account linking, or OAuth account schema** → official `state-manager-auth`
|
|
39
39
|
|
|
@@ -45,9 +45,9 @@ The official docs describe these major concepts:
|
|
|
45
45
|
|
|
46
46
|
- `AuthConfig.php` is the central place for defining route protection strategy and role-based route rules
|
|
47
47
|
- sessions are managed through Prisma PHP auth helpers rather than ad hoc cookie code
|
|
48
|
-
- `Auth::signIn(...)` creates the session payload
|
|
49
|
-
- `Auth::signOut(...)` ends the session and can redirect
|
|
50
|
-
- `refreshUserSession(...)` updates the active session payload when user permissions or profile data change
|
|
48
|
+
- `Auth::getInstance()->signIn(...)` creates the session payload
|
|
49
|
+
- `Auth::getInstance()->signOut(...)` ends the session and can redirect
|
|
50
|
+
- `Auth::getInstance()->refreshUserSession(...)` updates the active session payload when user permissions or profile data change
|
|
51
51
|
- route-level RBAC and function-level access control are separate but complementary concerns
|
|
52
52
|
|
|
53
53
|
## Security strategy
|
|
@@ -88,24 +88,24 @@ Mental model:
|
|
|
88
88
|
|
|
89
89
|
### Sign in
|
|
90
90
|
|
|
91
|
-
Use `Auth::signIn(...)` after credentials or provider identity are validated.
|
|
91
|
+
Use `Auth::getInstance()->signIn(...)` after credentials or provider identity are validated.
|
|
92
92
|
|
|
93
93
|
The session payload should contain the user data your app needs for identity and authorization decisions, commonly including:
|
|
94
94
|
|
|
95
95
|
- `id`
|
|
96
96
|
- `role`
|
|
97
97
|
|
|
98
|
-
Do not invent a separate session writer when the framework already documents `Auth::signIn(...)`.
|
|
98
|
+
Do not invent a separate session writer when the framework already documents `Auth::getInstance()->signIn(...)`.
|
|
99
99
|
|
|
100
100
|
### Sign out
|
|
101
101
|
|
|
102
|
-
Use `Auth::signOut(...)` to destroy the session and invalidate the client cookie.
|
|
102
|
+
Use `Auth::getInstance()->signOut(...)` to destroy the session and invalidate the client cookie.
|
|
103
103
|
|
|
104
104
|
When the flow needs a post-logout redirect, use the documented redirect argument instead of custom manual cookie clearing.
|
|
105
105
|
|
|
106
106
|
### Live session refresh
|
|
107
107
|
|
|
108
|
-
Use `refreshUserSession(...)` when a currently signed-in user’s auth payload must change immediately, such as:
|
|
108
|
+
Use `Auth::getInstance()->refreshUserSession(...)` when a currently signed-in user’s auth payload must change immediately, such as:
|
|
109
109
|
|
|
110
110
|
- role promotion or demotion
|
|
111
111
|
- profile data updates included in the auth payload
|
|
@@ -157,7 +157,7 @@ When backend functions are protected with `#[Exposed(allowedRoles: [...])]`, kee
|
|
|
157
157
|
|
|
158
158
|
The credentials docs describe the classic email/password flow as a full-stack Prisma PHP pattern where backend logic and form UI can live together in route files.
|
|
159
159
|
|
|
160
|
-
###
|
|
160
|
+
### Provider schema expectations
|
|
161
161
|
|
|
162
162
|
For credentials auth, the docs show a user model with fields such as:
|
|
163
163
|
|
|
@@ -185,7 +185,7 @@ The documented login flow uses:
|
|
|
185
185
|
- a route such as `src/app/auth/login/index.php`
|
|
186
186
|
- a user lookup through Prisma ORM
|
|
187
187
|
- `password_verify(...)` for password comparison
|
|
188
|
-
- `Auth::signIn(...)` with the session payload
|
|
188
|
+
- `Auth::getInstance()->signIn(...)` with the session payload
|
|
189
189
|
- a redirect after successful sign-in
|
|
190
190
|
|
|
191
191
|
### Validation rule
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Bootstrap and Runtime
|
|
3
|
+
description: Learn how Prisma PHP bootstraps requests, initializes runtime helpers, resolves routes, and protects function calls with cookies and FUNCTION_CALL_SECRET.
|
|
4
|
+
related:
|
|
5
|
+
title: Related docs
|
|
6
|
+
description: Use env for configuration, fetching-data for exposed functions, and error-handling for runtime failures.
|
|
7
|
+
links:
|
|
8
|
+
- /docs/env
|
|
9
|
+
- /docs/fetching-data
|
|
10
|
+
- /docs/error-handling
|
|
11
|
+
- /docs/project-structure
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
This page explains the Prisma PHP runtime bootstrap flow used by the current project scaffold.
|
|
15
|
+
|
|
16
|
+
If a task involves request initialization, route resolution, local-store callbacks, `FUNCTION_CALL_SECRET`, `prisma_php_csrf`, or the order in which Prisma PHP runtime helpers are initialized, AI agents should read this page first and keep generated code aligned with `bootstrap.php`.
|
|
17
|
+
|
|
18
|
+
## AI rule: read the bootstrap docs first
|
|
19
|
+
|
|
20
|
+
Before changing runtime bootstrap behavior, use this order:
|
|
21
|
+
|
|
22
|
+
1. Read `prisma-php.json`.
|
|
23
|
+
2. Read `env.md` for runtime configuration values.
|
|
24
|
+
3. Read this page for init order, request protection, and route resolution.
|
|
25
|
+
4. Read `fetching-data.md` when the task also involves `#[Exposed]` functions or streamed responses.
|
|
26
|
+
5. Inspect `bootstrap.php` only when the docs still leave a gap.
|
|
27
|
+
|
|
28
|
+
## Runtime init order
|
|
29
|
+
|
|
30
|
+
The current Prisma PHP bootstrap initializes the runtime in this order:
|
|
31
|
+
|
|
32
|
+
1. `date_default_timezone_set(Env::string('APP_TIMEZONE', 'UTC'))`
|
|
33
|
+
2. `PrismaPHPSettings::init()`
|
|
34
|
+
3. `Request::init()`
|
|
35
|
+
4. `StateManager::init()`
|
|
36
|
+
5. `MainLayout::init()`
|
|
37
|
+
6. `ErrorHandler::registerHandlers()`
|
|
38
|
+
7. set the `pp_local_store_key` cookie from `PrismaPHPSettings::$localStoreKey`
|
|
39
|
+
8. create or validate the `prisma_php_csrf` cookie
|
|
40
|
+
9. resolve the current route, included content file, and active layouts
|
|
41
|
+
10. run auth checks and fatal-error checks
|
|
42
|
+
|
|
43
|
+
When AI changes bootstrap-sensitive code, preserve that ordering unless the task is explicitly about changing the framework runtime.
|
|
44
|
+
|
|
45
|
+
## What `PrismaPHPSettings::init()` loads
|
|
46
|
+
|
|
47
|
+
The runtime reads Prisma PHP project settings from these files:
|
|
48
|
+
|
|
49
|
+
- `prisma-php.json`
|
|
50
|
+
- `settings/files-list.json`
|
|
51
|
+
- `settings/class-imports.json`
|
|
52
|
+
- `settings/request-data.json`
|
|
53
|
+
|
|
54
|
+
It also derives the local storage callback key from `LOCALSTORE_KEY` in the environment, normalized to a lowercase underscore-separated value.
|
|
55
|
+
|
|
56
|
+
## Request initialization
|
|
57
|
+
|
|
58
|
+
`Request::init()` normalizes the current request into the Prisma PHP request model.
|
|
59
|
+
|
|
60
|
+
That initialization populates:
|
|
61
|
+
|
|
62
|
+
- HTTP method flags such as `Request::$isGet`, `Request::$isPost`, and `Request::$isDelete`
|
|
63
|
+
- unified request parameters through `Request::$params`
|
|
64
|
+
- dynamic route parameters through `Request::$dynamicParams`
|
|
65
|
+
- local storage values through `Request::$localStorage`
|
|
66
|
+
- request metadata such as `Request::$uri`, `Request::$pathname`, `Request::$documentUrl`, and `Request::$requestedWith`
|
|
67
|
+
|
|
68
|
+
Do not invent a second request abstraction when the task already fits the current `PP\Request` model.
|
|
69
|
+
|
|
70
|
+
## Route resolution and layout collection
|
|
71
|
+
|
|
72
|
+
The bootstrap resolves the active content file from the incoming request URI and then collects matching layouts.
|
|
73
|
+
|
|
74
|
+
Important runtime rules:
|
|
75
|
+
|
|
76
|
+
- `AuthMiddleware::handle($pathname)` runs during route resolution
|
|
77
|
+
- grouped routes and dynamic routes are resolved before falling back to root precedence
|
|
78
|
+
- the root layout is collected first when it exists
|
|
79
|
+
- nested layouts are collected from the route tree
|
|
80
|
+
- `files-list.json` is read by the runtime, but consumer-app code should not edit it manually
|
|
81
|
+
|
|
82
|
+
For route creation or route placement, continue using `project-structure.md`, `layouts-and-pages.md`, and `route-handlers.md`.
|
|
83
|
+
|
|
84
|
+
## Local store callback contract
|
|
85
|
+
|
|
86
|
+
Prisma PHP reserves a browser callback channel for local storage synchronization.
|
|
87
|
+
|
|
88
|
+
The runtime sets a `pp_local_store_key` cookie using `PrismaPHPSettings::$localStoreKey`.
|
|
89
|
+
|
|
90
|
+
When the incoming `HTTP_X_PP_FUNCTION` header matches that local store key, Prisma PHP treats the request as a local-store callback and validates the CSRF token before returning JSON.
|
|
91
|
+
|
|
92
|
+
Do not replace that flow with a custom local storage callback protocol unless the task is explicitly about changing the framework runtime.
|
|
93
|
+
|
|
94
|
+
## Function-call CSRF contract
|
|
95
|
+
|
|
96
|
+
Prisma PHP protects callback-style requests with a CSRF token signed by `FUNCTION_CALL_SECRET`.
|
|
97
|
+
|
|
98
|
+
### `FUNCTION_CALL_SECRET`
|
|
99
|
+
|
|
100
|
+
`FUNCTION_CALL_SECRET` is required for CSRF protection.
|
|
101
|
+
|
|
102
|
+
If it is missing, bootstrap throws a runtime exception instead of silently disabling protection.
|
|
103
|
+
|
|
104
|
+
### `prisma_php_csrf`
|
|
105
|
+
|
|
106
|
+
The runtime stores the CSRF token in the `prisma_php_csrf` cookie.
|
|
107
|
+
|
|
108
|
+
The token format is:
|
|
109
|
+
|
|
110
|
+
- `nonce.signature`
|
|
111
|
+
|
|
112
|
+
The signature is an HMAC-SHA256 hash of the nonce using `FUNCTION_CALL_SECRET`.
|
|
113
|
+
|
|
114
|
+
If the cookie is missing or invalid, bootstrap generates a new token.
|
|
115
|
+
|
|
116
|
+
### Validation rules
|
|
117
|
+
|
|
118
|
+
Protected callback-style requests must send an `X-CSRF-TOKEN` header that exactly matches the `prisma_php_csrf` cookie.
|
|
119
|
+
|
|
120
|
+
Validation fails when:
|
|
121
|
+
|
|
122
|
+
- the secret is missing
|
|
123
|
+
- the header is missing
|
|
124
|
+
- the cookie is missing
|
|
125
|
+
- the header and cookie do not match
|
|
126
|
+
- the cookie format is invalid
|
|
127
|
+
- the HMAC signature does not validate
|
|
128
|
+
|
|
129
|
+
For these failures, bootstrap returns a JSON error response instead of allowing the callback to continue.
|
|
130
|
+
|
|
131
|
+
## Runtime guidance for AI agents
|
|
132
|
+
|
|
133
|
+
- when changing `.env` values related to runtime behavior, read `env.md` first
|
|
134
|
+
- when working on `#[Exposed]` functions, fetch callbacks, or streams, combine this page with `fetching-data.md`
|
|
135
|
+
- when the task touches route selection, layout wrapping, or route file choice, combine this page with `project-structure.md` and `layouts-and-pages.md`
|
|
136
|
+
- when runtime failures are expected, combine this page with `error-handling.md`
|
|
137
|
+
- do not remove or bypass `FUNCTION_CALL_SECRET`, `prisma_php_csrf`, or `pp_local_store_key` unless the task explicitly changes the security model
|
|
138
|
+
|
|
139
|
+
## Good to know
|
|
140
|
+
|
|
141
|
+
- Prisma PHP bootstrap initializes `MainLayout` before route files are rendered
|
|
142
|
+
- Prisma PHP bootstrap initializes `ErrorHandler` before runtime inclusion continues
|
|
143
|
+
- `PP\Request` is the normalized request source of truth
|
|
144
|
+
- `pp_local_store_key` and `prisma_php_csrf` are runtime cookies managed by bootstrap
|
|
145
|
+
- `FUNCTION_CALL_SECRET` is required for callback CSRF protection
|
package/dist/docs/commands.md
CHANGED
|
@@ -7,6 +7,7 @@ related:
|
|
|
7
7
|
links:
|
|
8
8
|
- /docs/installation
|
|
9
9
|
- /docs/upgrading
|
|
10
|
+
- /docs/typescript
|
|
10
11
|
---
|
|
11
12
|
|
|
12
13
|
This guide explains what each Prisma PHP CLI command does, when to use it, and how the create and update workflows fit together.
|
|
@@ -91,13 +92,13 @@ This flag enables non-interactive mode.
|
|
|
91
92
|
|
|
92
93
|
Instead of stopping for terminal prompts, the CLI proceeds with the provided flags and default values.
|
|
93
94
|
|
|
94
|
-
|
|
95
|
+
#### When to use `-y`
|
|
95
96
|
|
|
96
97
|
- running automation or CI
|
|
97
98
|
- scaffolding quickly without prompts
|
|
98
99
|
- generating predictable output from scripts
|
|
99
100
|
|
|
100
|
-
|
|
101
|
+
#### `-y` example
|
|
101
102
|
|
|
102
103
|
```bash package="npm"
|
|
103
104
|
npx create-prisma-php-app my-app -y
|
|
@@ -111,13 +112,13 @@ Creates a backend-only project.
|
|
|
111
112
|
|
|
112
113
|
This is appropriate for API-first or server-only applications where the project should center on handler-style routes instead of the usual full-stack page flow.
|
|
113
114
|
|
|
114
|
-
|
|
115
|
+
#### When to use `--backend-only`
|
|
115
116
|
|
|
116
117
|
- building REST APIs
|
|
117
118
|
- creating server-only services
|
|
118
119
|
- building a backend for a separate frontend client
|
|
119
120
|
|
|
120
|
-
|
|
121
|
+
#### `--backend-only` example
|
|
121
122
|
|
|
122
123
|
```bash package="npm"
|
|
123
124
|
npx create-prisma-php-app my-app --backend-only
|
|
@@ -129,13 +130,13 @@ Enables Swagger and OpenAPI documentation support.
|
|
|
129
130
|
|
|
130
131
|
This prepares the project for API schema generation and API documentation workflows.
|
|
131
132
|
|
|
132
|
-
|
|
133
|
+
#### When to use `--swagger-docs`
|
|
133
134
|
|
|
134
135
|
- documenting API endpoints
|
|
135
136
|
- sharing API contracts with frontend or third-party consumers
|
|
136
137
|
- generating OpenAPI-based tooling from the project
|
|
137
138
|
|
|
138
|
-
|
|
139
|
+
#### `--swagger-docs` example
|
|
139
140
|
|
|
140
141
|
```bash package="npm"
|
|
141
142
|
npx create-prisma-php-app my-app --backend-only --swagger-docs
|
|
@@ -147,13 +148,13 @@ Enables Tailwind CSS support.
|
|
|
147
148
|
|
|
148
149
|
This prepares frontend styling with Tailwind-related files and scripts.
|
|
149
150
|
|
|
150
|
-
|
|
151
|
+
#### When to use `--tailwindcss`
|
|
151
152
|
|
|
152
153
|
- building dashboards or admin panels
|
|
153
154
|
- creating a styled full-stack UI
|
|
154
155
|
- starting a project that should use utility-first CSS from day one
|
|
155
156
|
|
|
156
|
-
|
|
157
|
+
#### `--tailwindcss` example
|
|
157
158
|
|
|
158
159
|
```bash package="npm"
|
|
159
160
|
npx create-prisma-php-app my-app --tailwindcss
|
|
@@ -163,13 +164,17 @@ npx create-prisma-php-app my-app --tailwindcss
|
|
|
163
164
|
|
|
164
165
|
Enables TypeScript support for the frontend toolchain.
|
|
165
166
|
|
|
166
|
-
|
|
167
|
+
When this flag is enabled, Prisma PHP should keep frontend TypeScript in the root `ts/` directory, register browser helpers from `ts/main.ts`, and use those registered globals from template expressions and PulsePoint component scripts.
|
|
168
|
+
|
|
169
|
+
Read `typescript.md` for the TypeScript-specific workflow.
|
|
170
|
+
|
|
171
|
+
#### When to use `--typescript`
|
|
167
172
|
|
|
168
173
|
- you want typed frontend code
|
|
169
174
|
- you want stronger editor tooling for frontend work
|
|
170
175
|
- your project will include frontend TypeScript assets
|
|
171
176
|
|
|
172
|
-
|
|
177
|
+
#### `--typescript` example
|
|
173
178
|
|
|
174
179
|
```bash package="npm"
|
|
175
180
|
npx create-prisma-php-app my-app --typescript
|
|
@@ -181,13 +186,13 @@ Enables WebSocket support.
|
|
|
181
186
|
|
|
182
187
|
This prepares the project for real-time server and client workflows.
|
|
183
188
|
|
|
184
|
-
|
|
189
|
+
#### When to use `--websocket`
|
|
185
190
|
|
|
186
191
|
- building chat systems
|
|
187
192
|
- creating live dashboards
|
|
188
193
|
- sending notifications or push-style realtime updates
|
|
189
194
|
|
|
190
|
-
|
|
195
|
+
#### `--websocket` example
|
|
191
196
|
|
|
192
197
|
```bash package="npm"
|
|
193
198
|
npx create-prisma-php-app my-app --websocket
|
|
@@ -199,13 +204,13 @@ Enables MCP support.
|
|
|
199
204
|
|
|
200
205
|
This prepares the project for Model Context Protocol server and tool workflows.
|
|
201
206
|
|
|
202
|
-
|
|
207
|
+
#### When to use `--mcp`
|
|
203
208
|
|
|
204
209
|
- integrating AI tooling
|
|
205
210
|
- exposing tools through MCP
|
|
206
211
|
- building model-connected workflows
|
|
207
212
|
|
|
208
|
-
|
|
213
|
+
#### `--mcp` example
|
|
209
214
|
|
|
210
215
|
```bash package="npm"
|
|
211
216
|
npx create-prisma-php-app my-app --mcp
|
|
@@ -217,13 +222,13 @@ Enables Prisma ORM support.
|
|
|
217
222
|
|
|
218
223
|
This prepares the project for database-backed development and ORM generation workflows.
|
|
219
224
|
|
|
220
|
-
|
|
225
|
+
#### When to use `--prisma`
|
|
221
226
|
|
|
222
227
|
- your project needs a database
|
|
223
228
|
- you want Prisma ORM available from the start
|
|
224
229
|
- you are building CRUD apps, APIs, dashboards, or content systems
|
|
225
230
|
|
|
226
|
-
|
|
231
|
+
#### `--prisma` example
|
|
227
232
|
|
|
228
233
|
```bash package="npm"
|
|
229
234
|
npx create-prisma-php-app my-app --prisma
|
|
@@ -237,7 +242,7 @@ Shows the starter kits available in the installed CLI version.
|
|
|
237
242
|
|
|
238
243
|
Use this before choosing a starter if you want to inspect the currently supported templates.
|
|
239
244
|
|
|
240
|
-
|
|
245
|
+
#### `--list-starter-kits` example
|
|
241
246
|
|
|
242
247
|
```bash package="npm"
|
|
243
248
|
npx create-prisma-php-app --list-starter-kits
|
|
@@ -251,7 +256,7 @@ Starter kits provide opinionated starting points so you do not have to assemble
|
|
|
251
256
|
|
|
252
257
|
The exact built-in starter kit names depend on the installed CLI version, so `--list-starter-kits` is the safest way to confirm the current list.
|
|
253
258
|
|
|
254
|
-
|
|
259
|
+
#### `--starter-kit=<kit>` example
|
|
255
260
|
|
|
256
261
|
```bash package="npm"
|
|
257
262
|
npx create-prisma-php-app my-app --starter-kit=basic
|
|
@@ -263,7 +268,7 @@ Uses a custom external starter kit source.
|
|
|
263
268
|
|
|
264
269
|
This is intended for custom or team-managed boilerplates and is typically paired with `--starter-kit=custom`.
|
|
265
270
|
|
|
266
|
-
|
|
271
|
+
#### `--starter-kit-source=<url>` example
|
|
267
272
|
|
|
268
273
|
```bash package="npm"
|
|
269
274
|
npx create-prisma-php-app my-app --starter-kit=custom --starter-kit-source=https://github.com/user/repo
|
|
@@ -309,7 +314,7 @@ Use this when the project already exists and you want to regenerate or refresh f
|
|
|
309
314
|
|
|
310
315
|
If you are enabling or changing features on an existing project, update `prisma-php.json` first, then run `npx pp update project`.
|
|
311
316
|
|
|
312
|
-
|
|
317
|
+
#### `npx pp update project` example
|
|
313
318
|
|
|
314
319
|
```bash package="npm"
|
|
315
320
|
npx pp update project
|
|
@@ -319,7 +324,7 @@ npx pp update project
|
|
|
319
324
|
|
|
320
325
|
Refreshes the current project using the latest published version of `create-prisma-php-app`.
|
|
321
326
|
|
|
322
|
-
|
|
327
|
+
#### `npx pp update project @latest` example
|
|
323
328
|
|
|
324
329
|
```bash package="npm"
|
|
325
330
|
npx pp update project @latest
|
|
@@ -329,13 +334,13 @@ npx pp update project @latest
|
|
|
329
334
|
|
|
330
335
|
Refreshes the project using a tagged prerelease such as an alpha build.
|
|
331
336
|
|
|
332
|
-
|
|
337
|
+
#### When to use `npx pp update project @v5-alpha`
|
|
333
338
|
|
|
334
339
|
- testing prerelease framework changes
|
|
335
340
|
- validating upcoming CLI behavior
|
|
336
341
|
- trying an experimental version on an existing project
|
|
337
342
|
|
|
338
|
-
|
|
343
|
+
#### `npx pp update project @v5-alpha` example
|
|
339
344
|
|
|
340
345
|
```bash package="npm"
|
|
341
346
|
npx pp update project @v5-alpha
|
|
@@ -345,13 +350,13 @@ npx pp update project @v5-alpha
|
|
|
345
350
|
|
|
346
351
|
Refreshes the project using a fixed package version.
|
|
347
352
|
|
|
348
|
-
|
|
353
|
+
#### When to use `npx pp update project @1.2.3`
|
|
349
354
|
|
|
350
355
|
- you need reproducible updates
|
|
351
356
|
- you want to stay on a known working version
|
|
352
357
|
- you want strict version control over generator behavior
|
|
353
358
|
|
|
354
|
-
|
|
359
|
+
#### `npx pp update project @1.2.3` example
|
|
355
360
|
|
|
356
361
|
```bash package="npm"
|
|
357
362
|
npx pp update project @1.2.3
|
|
@@ -363,13 +368,13 @@ Runs the update in non-interactive mode.
|
|
|
363
368
|
|
|
364
369
|
This skips the confirmation prompt and proceeds directly.
|
|
365
370
|
|
|
366
|
-
|
|
371
|
+
#### When to use `npx pp update project -y`
|
|
367
372
|
|
|
368
373
|
- running scripted updates
|
|
369
374
|
- using CI or automation
|
|
370
375
|
- updating from AI-driven workflows
|
|
371
376
|
|
|
372
|
-
|
|
377
|
+
#### `npx pp update project -y` example
|
|
373
378
|
|
|
374
379
|
```bash package="npm"
|
|
375
380
|
npx pp update project -y
|
|
@@ -396,6 +401,135 @@ It is not a substitute for Prisma ORM schema migration commands.
|
|
|
396
401
|
|
|
397
402
|
If your database schema changed, use the Prisma ORM workflow documented in `prisma-php-orm.md` and `upgrading.md`.
|
|
398
403
|
|
|
404
|
+
## Prisma PHP Node Script Execution Guide
|
|
405
|
+
|
|
406
|
+
This section documents the generated Node script surface in Prisma PHP apps.
|
|
407
|
+
|
|
408
|
+
For normal Prisma PHP work, prefer the top-level entry points:
|
|
409
|
+
|
|
410
|
+
- `npm run dev` during development
|
|
411
|
+
- `npm run build` when you intentionally want a production-style asset build
|
|
412
|
+
|
|
413
|
+
Prisma PHP wires feature-specific scripts such as Tailwind, TypeScript, WebSocket, and MCP into those top-level commands when the matching feature is enabled.
|
|
414
|
+
|
|
415
|
+
That means AI agents should not default to telling users to run `npm run tailwind`, `npm run tailwind:build`, `npm run ts:watch`, or `npm run ts:build` after ordinary file changes. Those lower-level scripts are mainly useful when isolating one part of the toolchain, debugging, or running a feature-specific workflow on purpose.
|
|
416
|
+
|
|
417
|
+
### Script table
|
|
418
|
+
|
|
419
|
+
| Command | Type | What it does | When it exists | Use case |
|
|
420
|
+
| --- | --- | --- | --- | --- |
|
|
421
|
+
| `npm run projectName` | npm script | Runs `tsx settings/project-name.ts` so project name metadata stays aligned with the generated app setup. | Always added to generated `package.json`. | Internal setup step used before the main dev pipeline. |
|
|
422
|
+
| `npm run browserSync` | npm script | Runs `tsx settings/bs-config.ts` to start BrowserSync with the generated project config. | Always added. | Local development server and live reload. |
|
|
423
|
+
| `npm run browserSync:build` | npm script | Runs `tsx settings/build.ts` as the build-oriented BrowserSync step. | Always added. | Included in the normal build pipeline. |
|
|
424
|
+
| `npm run dev` | npm script | Runs `npm-run-all projectName -p browserSync ...` and adds feature-specific watch processes when those features are enabled. | Always added, but the parallel subtasks depend on enabled features. | Main local development command. |
|
|
425
|
+
| `npm run build` | npm script | Runs `npm-run-all ...` with build-oriented tasks such as `browserSync:build`, and optionally Tailwind and TypeScript build steps. | Always added, but included subtasks depend on enabled features. | Main build command for preparing project assets. |
|
|
426
|
+
| `npm run tailwind` | npm script | Runs `postcss src/app/globals.css -o public/css/styles.css --watch`. | Only when `tailwindcss` is enabled. | Feature-specific CSS watch mode when you need to isolate styling work. |
|
|
427
|
+
| `npm run tailwind:build` | npm script | Runs `postcss src/app/globals.css -o public/css/styles.css`. | Only when `tailwindcss` is enabled. | Feature-specific CSS build step, usually reached through `npm run build`. |
|
|
428
|
+
| `npm run ts:watch` | npm script | Runs `vite build --watch`. | Only when `typescript` is enabled and the project is not backend-only. | Feature-specific frontend TypeScript watch mode. |
|
|
429
|
+
| `npm run ts:build` | npm script | Runs `vite build`. | Only when `typescript` is enabled and the project is not backend-only. | Feature-specific frontend bundle step, usually reached through `npm run build`. |
|
|
430
|
+
| `npm run websocket` | npm script | Runs `tsx settings/restart-websocket.ts`. | Only when `websocket` is enabled. | Start or restart the WebSocket runtime in projects that use realtime features. |
|
|
431
|
+
| `npm run mcp` | npm script | Runs `tsx settings/restart-mcp.ts`. | Only when `mcp` is enabled. | Start or restart the MCP runtime in projects that expose MCP tools. |
|
|
432
|
+
| `npm run create-swagger-docs` | npm script | Runs the Prisma PHP Swagger docs generation flow and can optionally receive model names. | Only when `swaggerDocs` is enabled. | Generate or refresh Swagger and OpenAPI output. |
|
|
433
|
+
| `npx create-prisma-php-app <project-name>` | npx command | Creates a Prisma PHP project, installs dependencies, writes files, and saves the selected feature flags. | Available from the create CLI. | Scaffold a new project. |
|
|
434
|
+
| `npx create-prisma-php-app --list-starter-kits` | npx command | Prints the starter kits supported by the installed CLI version. | Always available in the create CLI. | Inspect available templates before choosing one. |
|
|
435
|
+
| `npx pp update project` | npx command | Reads `prisma-php.json` in the current app and refreshes the project using that saved configuration. | Available from the update CLI. | Refresh an existing project after saving feature changes or when updating framework-managed files. |
|
|
436
|
+
| `npx pp update project @latest` | npx command | Updates the current project using the latest published generator version. | Available from the update CLI. | Move an existing project to the newest published generator behavior. |
|
|
437
|
+
| `npx pp update project @v5-alpha` | npx command | Updates the current project using a tagged prerelease version such as an alpha build. | Available from the update CLI. | Test prerelease generator changes. |
|
|
438
|
+
| `npx pp update project @1.2.3` | npx command | Updates the current project using a fixed package version. | Available from the update CLI. | Use a pinned generator version for reproducible updates. |
|
|
439
|
+
| `npx pp update project -y` | npx command | Runs the update flow in non-interactive mode. | Available from the update CLI. | CI, scripts, or AI-driven update workflows. |
|
|
440
|
+
|
|
441
|
+
## How `npm run dev` is composed
|
|
442
|
+
|
|
443
|
+
`npm run dev` is generated around this base shape:
|
|
444
|
+
|
|
445
|
+
- `npm-run-all projectName -p browserSync ...conditional-watchers`
|
|
446
|
+
|
|
447
|
+
Possible parallel watchers added to `dev` are:
|
|
448
|
+
|
|
449
|
+
- `tailwind`
|
|
450
|
+
- `ts:watch`
|
|
451
|
+
- `websocket`
|
|
452
|
+
- `mcp`
|
|
453
|
+
|
|
454
|
+
That means:
|
|
455
|
+
|
|
456
|
+
- the base dev flow always includes `projectName` and `browserSync`
|
|
457
|
+
- Tailwind projects also run `tailwind`
|
|
458
|
+
- TypeScript frontend projects also run `ts:watch`
|
|
459
|
+
- WebSocket projects also run `websocket`
|
|
460
|
+
- MCP projects also run `mcp`
|
|
461
|
+
|
|
462
|
+
### Example `dev` combinations
|
|
463
|
+
|
|
464
|
+
| Project features | Resulting dev command shape |
|
|
465
|
+
| --- | --- |
|
|
466
|
+
| Minimal project | `npm-run-all projectName -p browserSync` |
|
|
467
|
+
| Tailwind only | `npm-run-all projectName -p browserSync tailwind` |
|
|
468
|
+
| Tailwind + TypeScript | `npm-run-all projectName -p browserSync tailwind ts:watch` |
|
|
469
|
+
| Tailwind + TypeScript + WebSocket + MCP | `npm-run-all projectName -p browserSync tailwind ts:watch websocket mcp` |
|
|
470
|
+
|
|
471
|
+
## How `npm run build` is composed
|
|
472
|
+
|
|
473
|
+
`npm run build` is generated from:
|
|
474
|
+
|
|
475
|
+
- base: `browserSync:build`
|
|
476
|
+
- plus `tailwind:build` when Tailwind is enabled
|
|
477
|
+
- plus `ts:build` when TypeScript is enabled and the project is not backend-only
|
|
478
|
+
|
|
479
|
+
### Example `build` combinations
|
|
480
|
+
|
|
481
|
+
| Project features | Resulting build command shape |
|
|
482
|
+
| --- | --- |
|
|
483
|
+
| Minimal project | `npm-run-all browserSync:build` |
|
|
484
|
+
| Tailwind only | `npm-run-all tailwind:build browserSync:build` |
|
|
485
|
+
| Tailwind + TypeScript | `npm-run-all ts:build tailwind:build browserSync:build` |
|
|
486
|
+
| TypeScript only | `npm-run-all ts:build browserSync:build` |
|
|
487
|
+
|
|
488
|
+
## Common execution examples
|
|
489
|
+
|
|
490
|
+
### Development
|
|
491
|
+
|
|
492
|
+
```bash package="npm"
|
|
493
|
+
npm run dev
|
|
494
|
+
npm run browserSync
|
|
495
|
+
npm run tailwind
|
|
496
|
+
npm run ts:watch
|
|
497
|
+
npm run websocket
|
|
498
|
+
npm run mcp
|
|
499
|
+
```
|
|
500
|
+
|
|
501
|
+
### Build
|
|
502
|
+
|
|
503
|
+
```bash package="npm"
|
|
504
|
+
npm run build
|
|
505
|
+
npm run browserSync:build
|
|
506
|
+
npm run tailwind:build
|
|
507
|
+
npm run ts:build
|
|
508
|
+
npm run create-swagger-docs
|
|
509
|
+
```
|
|
510
|
+
|
|
511
|
+
### Project scaffolding and update
|
|
512
|
+
|
|
513
|
+
```bash package="npm"
|
|
514
|
+
npx create-prisma-php-app my-app
|
|
515
|
+
npx create-prisma-php-app my-app --tailwindcss --typescript --prisma
|
|
516
|
+
npx create-prisma-php-app --list-starter-kits
|
|
517
|
+
|
|
518
|
+
npx pp update project
|
|
519
|
+
npx pp update project @latest
|
|
520
|
+
npx pp update project @v5-alpha
|
|
521
|
+
npx pp update project @1.2.3
|
|
522
|
+
npx pp update project -y
|
|
523
|
+
```
|
|
524
|
+
|
|
525
|
+
## Execution notes
|
|
526
|
+
|
|
527
|
+
- `npm run tailwind`, `npm run tailwind:build`, `npm run ts:watch`, `npm run ts:build`, `npm run websocket`, `npm run mcp`, and `npm run create-swagger-docs` are conditional scripts. They only exist when the matching feature was enabled for the project.
|
|
528
|
+
- For ordinary Prisma PHP development, start with `npm run dev` instead of manually running each watcher one by one.
|
|
529
|
+
- For ordinary build preparation, start with `npm run build` instead of manually running `tailwind:build` or `ts:build` unless you intentionally want to isolate those steps.
|
|
530
|
+
- `npx pp update project` rebuilds the update command from the saved `prisma-php.json` configuration, so you do not need to retype every feature flag.
|
|
531
|
+
- `npx pp update project` is a project refresh command, not an ORM migration shortcut.
|
|
532
|
+
|
|
399
533
|
## Recommended mental model
|
|
400
534
|
|
|
401
535
|
### Use create when
|
package/dist/docs/components.md
CHANGED
|
@@ -429,7 +429,7 @@ If you need explicit control over raw SSE event metadata, Prisma PHP also includ
|
|
|
429
429
|
Core locations in Prisma PHP:
|
|
430
430
|
|
|
431
431
|
```txt
|
|
432
|
-
vendor/tsnc/prisma-php/src/SSE.php
|
|
432
|
+
vendor/tsnc/prisma-php/src/Streaming/SSE.php
|
|
433
433
|
vendor/tsnc/prisma-php/src/Streaming/ServerSentEvent.php
|
|
434
434
|
```
|
|
435
435
|
|