You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> `sv` owns the file system - `sv.file()` resolves the path, reads the file, applies the edit function, and writes the result.
63
+
> `@sveltejs/sv-utils` owns the content - `transforms.svelte()` returns a curried function that handles parsing, gives you the AST and utils, and serializes back. See [sv-utils](/docs/cli/sv-utils) for the full API.
64
+
64
65
## Development with `file:` protocol
65
66
66
67
While developing your add-on, you can test it locally using the `file:` protocol:
@@ -77,8 +78,8 @@ This allows you to iterate quickly without publishing to npm.
77
78
The `sv/testing` module provides utilities for testing your add-on:
Community add-ons are bundled with [tsdown](https://tsdown.dev/) into a single file. Everything is bundled except `sv` (peer dependency, provided at runtime).
103
+
104
+
```sh
105
+
npm run build
106
+
```
98
107
99
108
### Package structure
100
109
101
-
Your add-on must have `sv` as a dependency in `package.json`:
110
+
Your add-on must have `sv` as a peer dependency and **no**`dependencies` in `package.json`:
102
111
103
112
```json
104
113
{
105
114
"name": "@your-org/sv",
106
115
"version": "1.0.0",
107
116
"type": "module",
108
117
"exports": {
109
-
".": "./dist/index.js"
118
+
".": "./src/index.js"
119
+
},
120
+
"publishConfig": {
121
+
"access": "public",
122
+
"exports": {
123
+
".": { "default": "./dist/index.js" }
124
+
}
110
125
},
111
-
"dependencies": {
112
-
"sv": "^0.11.0"
126
+
"peerDependencies": {
127
+
"sv": "^0.13.0"
113
128
},
114
129
"keywords": ["sv-add"]
115
130
}
116
131
```
117
132
133
+
-`exports` points to `./src/index.js` for local development with the `file:` protocol.
134
+
-`publishConfig.exports` overrides exports when publishing, pointing to the bundled `./dist/index.js`.
135
+
118
136
> [!NOTE]
119
137
> Add the `sv-add` keyword so users can discover your add-on on npm.
120
138
@@ -127,7 +145,7 @@ Your package can export the add-on in two ways:
127
145
```json
128
146
{
129
147
"exports": {
130
-
".": "./dist/index.js"
148
+
".": "./src/index.js"
131
149
}
132
150
}
133
151
```
@@ -136,17 +154,38 @@ Your package can export the add-on in two ways:
136
154
```json
137
155
{
138
156
"exports": {
139
-
".": "./dist/main.js",
140
-
"./sv": "./dist/addon.js"
157
+
".": "./src/main.js",
158
+
"./sv": "./src/addon.js"
141
159
}
142
160
}
143
161
```
144
162
145
-
### Naming conventions
163
+
### Publishing
164
+
165
+
Community add-ons must be scoped packages (e.g. `@your-org/sv`). Users install with `npx sv add @your-org`.
166
+
167
+
```sh
168
+
npm login
169
+
npm publish
170
+
```
171
+
172
+
> `prepublishOnly` automatically runs the build before publishing.
146
173
147
-
-**Scoped packages**: Use `@your-org/sv` as the package name. Users can then install with just `npx sv add @your-org`.
148
-
-**Regular packages**: Any name works. Users install with `npx sv add your-package-name`.
174
+
## Next steps
175
+
176
+
You can optionally display guidance after your add-on runs:
177
+
178
+
```js
179
+
// @noErrors
180
+
exportdefaultdefineAddon({
181
+
// ...
182
+
nextSteps: ({ options }) => [
183
+
`Run ${color.command('npm run dev')} to start developing`,
184
+
`Check out the docs at https://...`
185
+
]
186
+
});
187
+
```
149
188
150
189
## Version compatibility
151
190
152
-
Your add-on should specify the minimum `sv` version it requires in `package.json`. If a user's `sv` version has a different major version than what your add-on was built for, they will see a compatibility warning.
191
+
Your add-on should specify the minimum `sv` version it requires in `peerDependencies`. If a user's `sv` version has a different major version than what your add-on was built for, they will see a compatibility warning.
Copy file name to clipboardExpand all lines: documentation/docs/40-api/20-sv-utils.md
+191-1Lines changed: 191 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,5 +8,195 @@ title: sv-utils
8
8
`@sveltejs/sv-utils` provides utilities for parsing, transforming, and generating code in add-ons.
9
9
10
10
```sh
11
-
npm install @sveltejs/sv-utils
11
+
npm install -D @sveltejs/sv-utils
12
12
```
13
+
14
+
## Architecture
15
+
16
+
The Svelte CLI is split into two packages with a clear boundary:
17
+
18
+
-**`sv`** = **where and when** to do it. It owns paths, workspace detection, dependency tracking, and file I/O. The engine orchestrates add-on execution.
19
+
-**`@sveltejs/sv-utils`** = **what** to do to content. It provides parsers, language tooling, and typed transforms. Everything here is pure - no file system, no workspace awareness.
20
+
21
+
This separation means transforms are testable without a workspace and composable across add-ons.
22
+
23
+
## Transforms
24
+
25
+
Transforms are curried, parser-aware functions that turn `string -> string`. Call a transform with your callback to get a function that plugs directly into `sv.file()`. The parser choice is baked into the transform type - you can't accidentally parse a vite config as Svelte because you never call a parser yourself.
26
+
27
+
Each transform injects relevant utilities into the callback, so you only need one import:
28
+
29
+
```js
30
+
import { transforms } from'@sveltejs/sv-utils';
31
+
```
32
+
33
+
### `transforms.script`
34
+
35
+
Transform a JavaScript/TypeScript file. The callback receives `{ ast, comments, content, js }`.
Transform a Svelte component with a `<script>` block guaranteed. Pass `{ language }` as the first argument. The callback receives `{ ast, content, svelte, js }` where `ast.instance` is always non-null.
0 commit comments