@lumerahq/cli 0.19.15 → 0.19.16

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lumerahq/cli",
3
- "version": "0.19.15",
3
+ "version": "0.19.16",
4
4
  "description": "CLI for building and deploying Lumera apps",
5
5
  "type": "module",
6
6
  "engines": {
@@ -41,9 +41,9 @@ All resources use **external IDs** in the format `<app-name>:<resource-name>` (a
41
41
  **All collection names are automatically namespaced by project.** Always use bare names (e.g. `orders`, not `myproject__orders`) everywhere — in collection JSON files, Python SDK calls, JavaScript hooks, and frontend queries. The platform resolves bare names to the project-scoped version transparently.
42
42
 
43
43
  - `pb.ensure_collection("orders", ...)` → stored as `{project}__orders`
44
- - `pb.search("orders", ...)` → resolves to `{project}__orders`
44
+ - `query_sql("SELECT id FROM orders")` → resolves to `{project}__orders`
45
45
  - `ctx.dao.find("orders", ...)` → resolves to `{project}__orders`
46
- - `pbList("orders", ...)` in frontend → resolves via `X-Lumera-Project` header
46
+ - `pbSql({ sql: "SELECT id FROM orders" })` in frontend → resolves via `X-Lumera-Project` header
47
47
 
48
48
  **Never manually prefix collection names with `{project}__`.** Two projects can each have an `orders` collection — they are fully isolated.
49
49
 
@@ -96,10 +96,16 @@ Custom apps run in an **iframe**. **Always use the `@lumerahq/ui` bridge for API
96
96
 
97
97
  ```ts
98
98
  // ✅ Correct — uses postMessage bridge, no CORS issues
99
- import { pbSql, pbList, pbCreate, pbUpdate, pbDelete } from '@lumerahq/ui/lib';
99
+ import { pbSql, pbCreate, pbUpdate, pbDelete } from '@lumerahq/ui/lib';
100
+
101
+ // New read queries: use SQL for collection access, including lookups, lists, reports, joins, ordering, and filters
102
+ const result = await pbSql<{ id: string; amount: number }>({
103
+ sql: 'SELECT id, amount FROM orders WHERE status = {:status} ORDER BY updated DESC LIMIT 100',
104
+ params: { status: 'pending' },
105
+ });
106
+ const records = result.rows;
100
107
 
101
108
  // CRUD
102
- const records = await pbList('orders', { filter: JSON.stringify({ status: "pending" }) });
103
109
  await pbCreate('orders', { amount: 100 });
104
110
  await pbUpdate('orders', recordId, { status: 'done' });
105
111
  await pbDelete('orders', recordId);
@@ -113,6 +119,9 @@ fetch('https://app.lumerahq.com/api/pb/sql', ...);
113
119
 
114
120
  **Rules:**
115
121
  - Always import from `@lumerahq/ui/lib` — never write a custom `apiFetch` with raw `fetch()`
122
+ - Use `pbSql()` for new read-only collection access
123
+ - Existing `pbList()` / `pbSearch()` filter code remains supported for simple existing list/search reads; do not rewrite working code just because SQL exists
124
+ - Use record helpers such as `pbCreate()`, `pbUpdate()`, and `pbDelete()` for mutations
116
125
  - Token is not needed — the bridge handles auth via the parent session
117
126
  - `X-Lumera-Project` header is not needed — the parent adds it automatically
118
127