@pikku/deploy 0.12.11 → 0.12.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/CHANGELOG.md +17 -0
- package/dist/manifest.d.ts +9 -0
- package/dist/provider-adapter.d.ts +24 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,22 @@
|
|
|
1
1
|
# @pikku/deploy
|
|
2
2
|
|
|
3
|
+
## 0.12.13
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- cf40182: Deployed units that call `rpc.startWorkflow('x')` now get x's meta, so the call no longer fails with `WorkflowNotFoundError`. The inspector records `startsWorkflows` for literal `rpc.startWorkflow(...)` calls. It warns when a handler computes the workflow name or passes `rpc` to a helper, because the planner cannot see those calls.
|
|
8
|
+
|
|
9
|
+
With workflow queues, the deploy planner gives a starter unit the workflow meta and orchestrator queue meta only (new `--workflowMeta` filter), plus `workflow-state` and `queue` services. Without queues the start runs inline, so the whole workflow is bundled. Core's `startWorkflow` now requires the workflow registration only for inline runs; queued runs need only the meta.
|
|
10
|
+
|
|
11
|
+
## 0.12.12
|
|
12
|
+
|
|
13
|
+
### Patch Changes
|
|
14
|
+
|
|
15
|
+
- 1fe79bc: SQLite extensions now load under bun on macOS. Bun there opens Apple's SQLite, which is built without extension loading, so the CLI points bun at Homebrew's libsqlite3 (`brew install sqlite`) as it starts, or at the one `PIKKU_SQLITE_LIBRARY` names; without one it warns and carries on without extensions. A bun standalone build on macOS embeds that libsqlite3 and opens its database with it, and fails if the build machine has none. Linux is unchanged: bun there brings a SQLite that loads extensions, and node uses `node:sqlite` everywhere.
|
|
16
|
+
- 1fe79bc: A standalone build of a SQLite app now ships its `db.sqliteExtensions` (sqlite-vec's vec0 by default) inside the artifact, so a migration or query that uses them works in production the way it does under `pikku dev`. The node bundle loads them from `sqlite-extensions/` beside itself; a compiled bun binary embeds them and writes them out under `$PIKKU_DATA_DIR/.pikku-sqlite-extensions/` on start. The libraries are the build machine's, so an extension that cannot be resolved there fails the build; `[]` builds without them.
|
|
17
|
+
|
|
18
|
+
`createNodeSqliteKysely` and `createBunSqliteKysely` take an `extensions` list of library paths to load into the connection.
|
|
19
|
+
|
|
3
20
|
## 0.12.11
|
|
4
21
|
|
|
5
22
|
### Patch Changes
|
package/dist/manifest.d.ts
CHANGED
|
@@ -86,6 +86,15 @@ export interface DeploymentUnit {
|
|
|
86
86
|
* registered here as well as in its own gateway unit.
|
|
87
87
|
*/
|
|
88
88
|
invokedAgents?: string[];
|
|
89
|
+
/**
|
|
90
|
+
* Workflows a function in this unit starts by literal name with
|
|
91
|
+
* `rpc.startWorkflow(...)`, when the unit is not already a full
|
|
92
|
+
* workflow-state unit. With workflow queues, per-unit codegen bundles only
|
|
93
|
+
* their meta: a queued start creates the run from it and hands the run to
|
|
94
|
+
* the workflow's orchestrator unit, which holds the registration. Without
|
|
95
|
+
* them the start runs inline, so the whole workflow is bundled.
|
|
96
|
+
*/
|
|
97
|
+
startedWorkflows?: string[];
|
|
89
98
|
/** SHA-256 of final bundled artifact (set by build pipeline) */
|
|
90
99
|
bundleHash?: string;
|
|
91
100
|
/** Final bundle size in bytes (set by build pipeline) */
|
|
@@ -86,6 +86,23 @@ export interface EntryGenerationContext {
|
|
|
86
86
|
* the same reason.
|
|
87
87
|
*/
|
|
88
88
|
coercionImportPath?: string;
|
|
89
|
+
/**
|
|
90
|
+
* File names of the loadable SQLite extensions the build staged into
|
|
91
|
+
* `<unitDir>/sqlite-extensions/`, from `db.sqliteExtensions` (sqlite-vec's
|
|
92
|
+
* `vec0` by default). SQLite only; absent when there are none.
|
|
93
|
+
*
|
|
94
|
+
* Beside the directory is `sqlite-extensions.gen.js`, which embeds each
|
|
95
|
+
* one with `with { type: 'file' }` for a runtime that compiles to a single
|
|
96
|
+
* binary.
|
|
97
|
+
*/
|
|
98
|
+
sqliteExtensions?: string[];
|
|
99
|
+
/**
|
|
100
|
+
* File name of the libsqlite3 the build staged beside the extensions, for a
|
|
101
|
+
* runtime that must be pointed at one before it opens a database — bun on
|
|
102
|
+
* macOS, whose own is Apple's and cannot load extensions. Also embedded by
|
|
103
|
+
* `sqlite-extensions.gen.js`. Absent everywhere else.
|
|
104
|
+
*/
|
|
105
|
+
sqliteLibrary?: string;
|
|
89
106
|
};
|
|
90
107
|
/**
|
|
91
108
|
* The app's `pikkuServerLifecycle` export, when it declares one.
|
|
@@ -129,6 +146,13 @@ export interface ProviderAdapter {
|
|
|
129
146
|
* `wireQueue(...)` user code are unaffected.
|
|
130
147
|
*/
|
|
131
148
|
readonly workflowQueues?: boolean;
|
|
149
|
+
/**
|
|
150
|
+
* Whether the artifact opens SQLite through a libsqlite3 it has to carry
|
|
151
|
+
* itself. True for a compiled bun binary: on macOS bun otherwise opens
|
|
152
|
+
* Apple's SQLite, which cannot load extensions, so the build ships the host's
|
|
153
|
+
* own libsqlite3 and the entry points bun at it before the first open.
|
|
154
|
+
*/
|
|
155
|
+
readonly bundlesSqliteLibrary?: boolean;
|
|
132
156
|
/**
|
|
133
157
|
* Generate the entry file source for a deployment unit.
|
|
134
158
|
* Called once per unit.
|