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
|
@@ -34,10 +34,14 @@ Before enabling or regenerating Swagger docs, use this order:
|
|
|
34
34
|
|
|
35
35
|
1. Inspect `prisma-php.json` for `swaggerDocs` and `backendOnly`.
|
|
36
36
|
2. Read `backend-only.md`, `route-handlers.md`, and `prisma-php-orm.md` as needed for the surrounding API workflow.
|
|
37
|
-
3. Use `npm run create-swagger-docs` for the documented generation flow.
|
|
37
|
+
3. Use `npm run create-swagger-docs` for the documented on-demand generation flow.
|
|
38
38
|
4. Inspect `settings/prisma-schema-config.json` before changing output paths or generation modes.
|
|
39
39
|
5. Do not treat Swagger generation as a substitute for ORM migrations or route implementation.
|
|
40
40
|
|
|
41
|
+
Unlike generated Tailwind or TypeScript build/watch scripts, Swagger generation is not the normal framework-managed step that runs as part of everyday `npm run dev` or `npm run build` work.
|
|
42
|
+
|
|
43
|
+
AI agents should treat `npm run create-swagger-docs` as an explicit documentation or contract-generation action and run it only when Swagger output actually needs to be created or refreshed.
|
|
44
|
+
|
|
41
45
|
## When Swagger docs are worth enabling
|
|
42
46
|
|
|
43
47
|
Enable Swagger docs when you need a stable machine-readable contract for the API.
|
|
@@ -80,6 +84,10 @@ That JSON file is the handoff point for tools such as:
|
|
|
80
84
|
|
|
81
85
|
Prisma PHP's Swagger workflow supports generating documentation for models from `schema.prisma`.
|
|
82
86
|
|
|
87
|
+
Use this command intentionally when your OpenAPI output needs to be updated.
|
|
88
|
+
|
|
89
|
+
Do not confuse it with framework-managed development scripts such as `npm run dev` or asset build orchestration through `npm run build`.
|
|
90
|
+
|
|
83
91
|
```bash package="npm"
|
|
84
92
|
npm run create-swagger-docs
|
|
85
93
|
npm run create-swagger-docs Order
|
|
@@ -135,7 +143,7 @@ For API-oriented Prisma PHP work, a practical Swagger workflow is:
|
|
|
135
143
|
|
|
136
144
|
1. update `schema.prisma`
|
|
137
145
|
2. run the normal ORM workflow when the schema changed
|
|
138
|
-
3. regenerate Swagger docs
|
|
146
|
+
3. regenerate Swagger docs only when the contract output needs to be refreshed
|
|
139
147
|
4. inspect `src/app/swagger-docs/apis/pphp-swagger.json`
|
|
140
148
|
5. regenerate external clients if the contract changed
|
|
141
149
|
|
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: TypeScript & NPM
|
|
3
|
+
nav_title: TypeScript
|
|
4
|
+
description: Learn how Prisma PHP uses the `typescript` feature flag so AI agents can place TypeScript in `ts/`, register browser helpers from `ts/main.ts`, and use them safely from PulsePoint component roots.
|
|
5
|
+
related:
|
|
6
|
+
title: Related docs
|
|
7
|
+
description: Read the Prisma PHP docs that define feature flags, project updates, and PulsePoint component boundaries before generating TypeScript-aware examples.
|
|
8
|
+
links:
|
|
9
|
+
- /docs/commands
|
|
10
|
+
- /docs/upgrading
|
|
11
|
+
- /docs/project-structure
|
|
12
|
+
- /docs/pulsepoint
|
|
13
|
+
- /docs/components
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
Prisma PHP TypeScript support should follow the framework's Vite-backed frontend workflow, not ad hoc inline module imports inside `index.php`, `layout.php`, or imported partials.
|
|
17
|
+
|
|
18
|
+
If a task involves the `typescript` flag in `prisma-php.json`, the root `ts/` directory, `ts/main.ts`, frontend npm packages, or using registered browser helpers inside PulsePoint templates and scripts, AI agents should read this page first and keep the implementation aligned with Prisma PHP's component boundary rules.
|
|
19
|
+
|
|
20
|
+
## AI rule: read the TypeScript docs first
|
|
21
|
+
|
|
22
|
+
Before generating, editing, or reviewing TypeScript-related frontend code, use this order:
|
|
23
|
+
|
|
24
|
+
1. Read `./prisma-php.json` in a generated Prisma PHP app and confirm whether `typescript` is enabled.
|
|
25
|
+
2. For an existing app, enable `typescript` first, then run `npx pp update project -y`.
|
|
26
|
+
3. Keep reusable frontend TypeScript modules in the root `ts/` directory.
|
|
27
|
+
4. Use `ts/main.ts` as the entry file that registers browser helpers for runtime use.
|
|
28
|
+
5. Use those registered globals from template expressions and PulsePoint component scripts.
|
|
29
|
+
6. Keep inline route or partial `<script>` blocks as plain JavaScript. Do not place `import` or `export` inside them.
|
|
30
|
+
|
|
31
|
+
Do not guess from React, Vue, Next.js, or generic Vite projects alone. Prisma PHP still follows its own PulsePoint component and route-file rules.
|
|
32
|
+
|
|
33
|
+
## Read this doc when you need
|
|
34
|
+
|
|
35
|
+
- **the `typescript` feature flag in `prisma-php.json` or the `--typescript` create flag** -> `commands.md`, `upgrading.md`, and `typescript.md`
|
|
36
|
+
- **where TypeScript files should live in a Prisma PHP app** -> `project-structure.md` and `typescript.md`
|
|
37
|
+
- **how to use registered browser helpers inside a normal PulsePoint route root** -> `layouts-and-pages.md`, `pulsepoint.md`, and `typescript.md`
|
|
38
|
+
- **how to use the same helpers inside an imported single-root partial** -> `components.md` and `typescript.md`
|
|
39
|
+
- **installing npm packages for frontend utilities** -> `typescript.md`
|
|
40
|
+
|
|
41
|
+
## When TypeScript is enabled
|
|
42
|
+
|
|
43
|
+
When `typescript` is enabled in `prisma-php.json`, Prisma PHP can use a Vite-powered frontend TypeScript workflow.
|
|
44
|
+
|
|
45
|
+
The practical rules are:
|
|
46
|
+
|
|
47
|
+
- keep browser-side TypeScript modules in `ts/`
|
|
48
|
+
- use `ts/main.ts` as the registration entry file
|
|
49
|
+
- install npm packages normally
|
|
50
|
+
- expose the browser helpers you want to call from templates or PulsePoint scripts
|
|
51
|
+
- keep inline PulsePoint scripts as plain JavaScript and call the registered globals from there
|
|
52
|
+
|
|
53
|
+
## Enable TypeScript in a new or existing app
|
|
54
|
+
|
|
55
|
+
### New project
|
|
56
|
+
|
|
57
|
+
```bash package="npm"
|
|
58
|
+
npx create-prisma-php-app my-app --typescript
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### Existing project
|
|
62
|
+
|
|
63
|
+
Enable the feature in `prisma-php.json`, then refresh the project files.
|
|
64
|
+
|
|
65
|
+
```json filename="prisma-php.json"
|
|
66
|
+
{
|
|
67
|
+
"projectName": "my-app",
|
|
68
|
+
"typescript": true
|
|
69
|
+
}
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
```bash package="npm"
|
|
73
|
+
npx pp update project -y
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
For broader project refresh guidance, read `upgrading.md`.
|
|
77
|
+
|
|
78
|
+
After TypeScript scaffolding exists, ordinary local work should still start from the framework-managed entry points:
|
|
79
|
+
|
|
80
|
+
- `npm run dev` for normal development
|
|
81
|
+
- `npm run build` when you intentionally want a production-style asset build
|
|
82
|
+
|
|
83
|
+
Do not default to `npm run ts:watch` or `npm run ts:build` after routine TypeScript edits unless you intentionally need to isolate the frontend bundle step.
|
|
84
|
+
|
|
85
|
+
## The `ts/` directory
|
|
86
|
+
|
|
87
|
+
For organization and reuse, keep frontend TypeScript logic in the root `ts/` directory.
|
|
88
|
+
|
|
89
|
+
This keeps module code out of route files and makes the frontend entry pipeline explicit.
|
|
90
|
+
|
|
91
|
+
Example layout:
|
|
92
|
+
|
|
93
|
+
```txt
|
|
94
|
+
ts/
|
|
95
|
+
├── date-utils.ts
|
|
96
|
+
├── global-functions.ts
|
|
97
|
+
├── main.ts
|
|
98
|
+
└── to-money.ts
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Example utility:
|
|
102
|
+
|
|
103
|
+
```ts filename="ts/to-money.ts"
|
|
104
|
+
export function toMoney(value: number): string {
|
|
105
|
+
return `$${value.toFixed(2)}`;
|
|
106
|
+
}
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
## Use any npm package
|
|
110
|
+
|
|
111
|
+
Because this workflow is Vite-backed, you can install npm packages and import them directly into files under `ts/`.
|
|
112
|
+
|
|
113
|
+
```bash package="npm"
|
|
114
|
+
npm install date-fns
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
```ts filename="ts/date-utils.ts"
|
|
118
|
+
import { format } from "date-fns";
|
|
119
|
+
|
|
120
|
+
export function getToday(): string {
|
|
121
|
+
return format(new Date(), "yyyy-MM-dd");
|
|
122
|
+
}
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
## Register helpers in `ts/main.ts`
|
|
126
|
+
|
|
127
|
+
Use the TypeScript entry file to register the browser helpers you want available globally.
|
|
128
|
+
|
|
129
|
+
```ts filename="ts/main.ts"
|
|
130
|
+
import { createGlobalSingleton } from "./global-functions";
|
|
131
|
+
import { getToday } from "./date-utils";
|
|
132
|
+
import { toMoney } from "./to-money";
|
|
133
|
+
|
|
134
|
+
createGlobalSingleton("getToday", getToday);
|
|
135
|
+
createGlobalSingleton("toMoney", toMoney);
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
After registration, those helpers can be used from Prisma PHP template expressions and PulsePoint component scripts without adding `import` statements inside the route file itself.
|
|
139
|
+
|
|
140
|
+
## Important PulsePoint boundary
|
|
141
|
+
|
|
142
|
+
Prisma PHP inline component scripts are plain JavaScript, not module files.
|
|
143
|
+
|
|
144
|
+
That means the right split is:
|
|
145
|
+
|
|
146
|
+
- write reusable module logic in `ts/`
|
|
147
|
+
- register the pieces you need from `ts/main.ts`
|
|
148
|
+
- call those registered helpers from the inline PulsePoint script inside the component root
|
|
149
|
+
- do not place `import` or `export` inside the inline route or imported-partial script
|
|
150
|
+
|
|
151
|
+
When the UI lives in `index.php` or nested `layout.php`, keep the normal Prisma PHP route structure:
|
|
152
|
+
|
|
153
|
+
1. PHP first
|
|
154
|
+
2. one parent HTML element
|
|
155
|
+
3. `pp-component` on that route root when PulsePoint is present
|
|
156
|
+
4. one `<script>` block as the last child inside that same root element
|
|
157
|
+
|
|
158
|
+
When the UI lives in an imported partial rendered through `ImportComponent::render(...)`, keep exactly one root element and place any component-local `<script>` inside that root. Do not manually add `pp-component` inside the imported partial source.
|
|
159
|
+
|
|
160
|
+
## Usage inside a PulsePoint route
|
|
161
|
+
|
|
162
|
+
This example keeps the route in the current Prisma PHP single-root component pattern while calling helpers registered from `ts/main.ts`.
|
|
163
|
+
|
|
164
|
+
```php filename="src/app/index.php"
|
|
165
|
+
<?php
|
|
166
|
+
|
|
167
|
+
use PP\MainLayout;
|
|
168
|
+
|
|
169
|
+
MainLayout::$title = 'TypeScript Helpers';
|
|
170
|
+
MainLayout::$description = 'Use registered TypeScript helpers from a PulsePoint route.';
|
|
171
|
+
?>
|
|
172
|
+
|
|
173
|
+
<section pp-component="typescript-demo-page">
|
|
174
|
+
<h1>TypeScript helpers</h1>
|
|
175
|
+
<p>Today: {getToday()}</p>
|
|
176
|
+
<p>Catalog price: {toMoney(1234.56)}</p>
|
|
177
|
+
<p>Discounted price: {discountedPrice}</p>
|
|
178
|
+
|
|
179
|
+
<button onclick="applyDiscount()">Apply discount</button>
|
|
180
|
+
|
|
181
|
+
<script>
|
|
182
|
+
const [discountedPrice, setDiscountedPrice] = pp.state(toMoney(15245));
|
|
183
|
+
|
|
184
|
+
function applyDiscount() {
|
|
185
|
+
setDiscountedPrice(toMoney(11999.5));
|
|
186
|
+
}
|
|
187
|
+
</script>
|
|
188
|
+
</section>
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
The helper calls stay available in both template expressions and the inline PulsePoint script, while the route still follows the documented Prisma PHP component boundary rules.
|
|
192
|
+
|
|
193
|
+
## AI rules for TypeScript tasks
|
|
194
|
+
|
|
195
|
+
- inspect `prisma-php.json` first and confirm whether `typescript` is enabled
|
|
196
|
+
- for existing apps, enable the feature and run `npx pp update project -y` before assuming the TypeScript scaffold exists
|
|
197
|
+
- keep reusable module code in `ts/`
|
|
198
|
+
- register browser helpers from `ts/main.ts`
|
|
199
|
+
- use npm packages through normal imports inside `ts/` files
|
|
200
|
+
- do not place `import` or `export` inside inline PulsePoint scripts in `index.php`, `layout.php`, or imported partials
|
|
201
|
+
- keep normal route files in the single-root PulsePoint pattern with the `<script>` as the last child inside the route root
|
|
202
|
+
- keep `ImportComponent` partials in the single-root pattern and let Prisma PHP inject `pp-component` there automatically
|
package/dist/docs/upgrading.md
CHANGED
|
@@ -47,6 +47,17 @@ npx pp update project -y
|
|
|
47
47
|
|
|
48
48
|
This ensures the update process applies the correct files, dependencies, and project structure for the features you selected.
|
|
49
49
|
|
|
50
|
+
For feature flags such as `tailwindcss`, `typescript`, `websocket`, and `mcp`, the updater's job is to refresh the generated files and scripts that the framework expects.
|
|
51
|
+
|
|
52
|
+
After that, AI agents should not default to telling users to manually run each feature-specific package script one by one.
|
|
53
|
+
|
|
54
|
+
For ordinary local verification after an update, prefer:
|
|
55
|
+
|
|
56
|
+
- `npm run dev` for the normal development workflow
|
|
57
|
+
- `npm run build` when you intentionally want a production-style asset build
|
|
58
|
+
|
|
59
|
+
Use lower-level scripts such as Tailwind, TypeScript, WebSocket, or MCP commands only when isolating a specific part of the toolchain, debugging, or running a feature-specific workflow on purpose.
|
|
60
|
+
|
|
50
61
|
If the feature you are enabling is API-focused, read `backend-only.md` for `backendOnly` usage and `swagger-docs.md` for `swaggerDocs` generation workflow details.
|
|
51
62
|
|
|
52
63
|
## Typical upgrade flow
|
|
@@ -155,7 +166,7 @@ After updating your project, verify the following:
|
|
|
155
166
|
|
|
156
167
|
- Your enabled features in `prisma-php.json` match the current project requirements.
|
|
157
168
|
- Dependencies installed correctly.
|
|
158
|
-
- Local development still runs as expected.
|
|
169
|
+
- Local development still runs as expected, normally through `npm run dev` rather than individual watcher scripts.
|
|
159
170
|
- Any custom files listed in `excludeFiles` were preserved.
|
|
160
171
|
- Database and generated ORM classes are in sync if schema changes were included.
|
|
161
172
|
|
package/dist/docs/websocket.md
CHANGED
|
@@ -84,6 +84,10 @@ The broader Prisma PHP project structure docs also show a development helper tha
|
|
|
84
84
|
|
|
85
85
|
- `settings/restart-websocket.ts`
|
|
86
86
|
|
|
87
|
+
Some Prisma PHP setups also wire websocket restart behavior into `npm run dev`.
|
|
88
|
+
|
|
89
|
+
AI should inspect the current `package.json` before telling users to run `npm run websocket` manually, and should prefer the normal development flow unless websocket startup needs to be isolated or debugged on purpose.
|
|
90
|
+
|
|
87
91
|
Important casing rule:
|
|
88
92
|
|
|
89
93
|
The official page may show lowercase path examples such as `src/lib/websocket`, but Prisma PHP project structure docs use `src/Lib`, and this repo's guidance expects application libraries under `src/Lib`.
|