vela 0.14.1 → 0.14.3
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/README.md +23 -8
- package/dist/bin.js +2627 -2390
- package/dist/bin.js.map +4 -4
- package/package.json +2 -2
- package/templates/server/apply.sh +28 -8
- package/templates/server/lib.sh +45 -2
- package/templates/server/restore.sh +1 -1
- package/templates/server/rollback.sh +1 -1
- package/templates/static/vite.config.ts +16 -1
package/README.md
CHANGED
|
@@ -60,10 +60,13 @@ Any SvelteKit project deploys this way, PocketBase or not — `npx sv create my-
|
|
|
60
60
|
straight into `vela deploy` works. The deploy looks at the project rather than at a
|
|
61
61
|
config: a server needs `@sveltejs/adapter-node`, so a project still on `adapter-auto`
|
|
62
62
|
(what `sv create` gives you) is switched to it on the first deploy, the package
|
|
63
|
-
installed, and you are asked to commit the change.
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
63
|
+
installed, and you are asked to commit the change. At a terminal the deploy asks before
|
|
64
|
+
it edits the config file and `package.json`; in CI it goes ahead. A project on
|
|
65
|
+
`adapter-static` or a hosting platform's adapter is left alone and told why. The server
|
|
66
|
+
installs dependencies with npm, so a pnpm, yarn or bun project should commit a
|
|
67
|
+
`package-lock.json` for a reproducible deploy; the deploy warns when it finds only theirs.
|
|
68
|
+
Nothing on the server assumes a database: run `vela enable backend` whenever you want
|
|
69
|
+
one and deploy again, and the same instance gains its PocketBase.
|
|
67
70
|
|
|
68
71
|
That first deploy binds `production` to the server, so nothing after it names a
|
|
69
72
|
machine again. Every command takes the same selector — `-t local`, `-t production`
|
|
@@ -97,12 +100,24 @@ Same thing from CI with [`velastack/action`](https://github.com/velastack/action
|
|
|
97
100
|
## Already have a project?
|
|
98
101
|
|
|
99
102
|
```sh
|
|
100
|
-
vela
|
|
103
|
+
vela enable backend # just PocketBase and the server test harness
|
|
104
|
+
vela bless # the full upgrade: Tailwind, shadcn-svelte, vela's layout and routes, the backend
|
|
101
105
|
```
|
|
102
106
|
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
107
|
+
Both work in place on a vanilla SvelteKit project. A project that is already deployed
|
|
108
|
+
keeps deploying to the same instance, now with a database.
|
|
109
|
+
|
|
110
|
+
Much of `vela` needs neither. In a plain `npx sv create` project, with no setup:
|
|
111
|
+
|
|
112
|
+
- `vela generate schema` and `vela generate form`, the form in plain HTML
|
|
113
|
+
- `vela enable i18n`, `ai`, `analytics`, `content-negotiation` and `cms`
|
|
114
|
+
- `vela legal` and `vela routes`
|
|
115
|
+
- `vela deploy`, `env`, `status`, `logs` and `rollback`
|
|
116
|
+
|
|
117
|
+
`vela ui`, `vela enable blog`, `vela enable auth` and what builds on it, and
|
|
118
|
+
`vela generate scaffold` write shadcn-svelte markup. Without it they refuse before
|
|
119
|
+
changing anything and name the setup: `npx sv add tailwindcss`, then
|
|
120
|
+
`npx shadcn-svelte@latest init`.
|
|
106
121
|
|
|
107
122
|
## It stays your code
|
|
108
123
|
|