Skip to content

Commit 9f0d3ae

Browse files
committed
fix(docs): added more details on inject command
1 parent 9305b37 commit 9f0d3ae

File tree

5 files changed

+79
-26
lines changed

5 files changed

+79
-26
lines changed

README.md

Lines changed: 22 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -26,12 +26,12 @@ Check the [FAQ](#faq) fro more on these.
2626
- [Verify plugin package](#verify-plugin-package)
2727
- [Upgrading a v2 plugin](#upgrading-a-v2-plugin)
2828
- [Upgrade help in v2 Studio](#upgrade-help-in-v2-studio)
29-
- [Inject config into existing v3 plugin](#inject-config-into-existing-v3)
29+
- [Inject config into existing v3 plugin](#inject-config-into-existing-package)
3030
- [Testing a plugin in Sanity Studio](#testing-a-plugin-in-sanity-studio)
3131
- [Upgrading from plugin-kit 1.x](#upgrade-from-v1x-to-v2)
3232
- [FAQ](#faq) aka "Do I _have_ to use this plugin-kit?" aka No
3333
- [Configuration reference](#configuration-reference)
34-
- [Developing plugin-kit](#developing-plugin-kit)
34+
- [Developing plugin-kit](#develop-plugin-kit)
3535

3636
## Installation
3737

@@ -140,7 +140,10 @@ Each check will explain why it is needed, steps to fix it and how it can be indi
140140

141141
### What it is _not_
142142

143-
`verify-package` is _not_ a codemod tool (yet). It will only check files and recommended settings: it will not change any files.
143+
`verify-package` is _not_ a codemod tool. It will only check files and recommended settings: it will not change any files.
144+
145+
Consider using `npx @sanity/plugin-kit inject` if you want to add recommended V3 plugin configuration automatically.
146+
See the [Inject docs](#inject-config-into-existing-package) for more on this.
144147

145148
### Upgrading a v2 plugin
146149

@@ -178,16 +181,29 @@ npx @sanity/plugin-kit verify-package --studio --single
178181

179182
This will only output the first validation that fails. Useful when working through the list of issues by fixing and rerunning the command.
180183

181-
### Inject config into existing v3
184+
## Inject config into existing package
182185

183-
Consult the inject command CLI help:
186+
```
187+
npx @sanity/plugin-kit inject
188+
```
189+
will inject recommended V3 plugin package boilerplate into an existing plugin.
190+
Be sure to commit any local changes before running this command, so you can easily revert anything
191+
you dont want.
184192

193+
Consult the inject command CLI help:
185194
```
186195
npx @sanity/plugin-kit inject --help
187196
```
188197

189198
for up-to-date specifics.
190199

200+
### Presets
201+
202+
The inject command can do more work by adding presets. Consult the individual preset docs for details:
203+
204+
* [semver-workflow](./docs/semver-workflow.md) - Add an opinionated Github workflow to automate NPM releases
205+
* [renovatebot](./docs/renovatebot.md) - Add opinionated Renovatebot config to make dependency management a breeze
206+
191207
## Testing a plugin in Sanity Studio
192208

193209
Ensure you have the following script setup in package.json:
@@ -465,7 +481,7 @@ npm run test -- test/verify-package.test.ts
465481
npm run test -- test/verify-package.test.ts --snapshot
466482
```
467483

468-
## Developing plugin kit
484+
## Develop plugin-kit
469485

470486
### Release new version
471487

58.7 KB
Loading

docs/renovatebot.md

Lines changed: 12 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,23 @@
11
# Preset: renovatebot
22

3-
## Manual steps after inject
3+
## Usage
44

5-
After injection, Renovate bot must be enabled for the repo on Github.
5+
### Inject into existing package
6+
`npx @sanity/plugin-kit inject --preset-only --preset renovatebot`
67

7-
This can be done by adding the repo to Github Renovatebot app allow-list.
8+
### Use to init plugin
9+
`npx @sanity/plugin-kit init --preset renovatebot <new-plugin-name>`
810

911
## What does it do?
1012

1113
Sets up the repo
1214

1315
- Adds Sanity dependabot preset dependency.
1416
- Adds `renovate.json` to configure the above dependency for Renovatebot
17+
18+
## Manual steps after inject
19+
20+
After injection, Renovate bot must be enabled for the repo on Github.
21+
22+
This can be done by adding the repo to Github Renovatebot app allow-list.
23+

docs/semver-workflow.md

Lines changed: 44 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,36 @@
11
# Preset: semver-workflow
22

3-
Add opinionated config and dependencies used by the Ecosystem team on Sanity to develop using
4-
semantic-release driven workflow on Github for Sanity v3 plugins.
3+
## Usage
4+
5+
### Inject into existing package
6+
`npx @sanity/plugin-kit inject --preset-only --preset semver-workflow`
7+
8+
### Use to init plugin
9+
`npx @sanity/plugin-kit init --preset semver-workflow <new-plugin-name>`
10+
11+
## What does it do?
12+
13+
Adds opinionated config and dependencies used by the Ecosystem team on Sanity, to develop using
14+
semantic-release driven workflow on Github.
15+
16+
![Github workflow](assets/semver-workflow-example.png)
17+
18+
This preset:
19+
20+
- adds [husky](https://github.com/typicode/husky) for pre-commit hooks to ensure that:
21+
- all commits follow [conventional-commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) format
22+
- all files in a commit pass eslint
23+
- [semantic-release](https://semantic-release.gitbook.io/semantic-release/) automation for npm publish
24+
- automates Github releases
25+
- updates package version based on conventional-commits
26+
- updates CHANGELOG.md
27+
- [GitHub workflow](https://docs.github.com/en/actions/using-workflows) (Action) that
28+
- does continuous integration
29+
- has publish-on-demand support which delegates to semantic-release
30+
- updates README.md with some standard texts, if missing
31+
32+
Keep in mind that this setup is tailored to the needs of the Ecosystem team at Sanity.
33+
Feel free to modify any and all files injected by the preset, or use it as a basis for creating your own workflow.
534

635
## Manual steps after inject
736

@@ -20,18 +49,18 @@ Some text could be redundant or unnecessary depending on context and search for
2049

2150
Move text around until it looks good. Remember to change any v2 usage examples.
2251

23-
### 3. Update `.github/workflows/main.yml` branches
52+
### 3. Check `.github/workflows/main.yml` branches
2453

2554
This differs from repo to repo, default is `[main]`
2655

27-
In a typical plugin repo with a v2 and v3 version, it will typically look like this:
56+
In a plugin repo with a v2 and v3 version, it could look like this:
2857

2958
```yml
3059
# .github/workflows/main.yml
3160
name: CI & Release
3261
on:
3362
push:
34-
branches: [main, v3]
63+
branches: [main, studio-v2]
3564
```
3665
3766
### 4. Check secrets
@@ -44,7 +73,7 @@ Ensure that your repo or Github org has set the secrets used by the workflow.
4473
Secrets can be set using `Settings -> Secrets -> Actions -> "New repository secret"`
4574
on Github for a repository.
4675

47-
### 5. Update .releaserc.json
76+
### 5. Check .releaserc.json
4877

4978
This differs from repo to repo. Branches defaults to `"branches": ["main"]`
5079

@@ -53,12 +82,13 @@ In a typical plugin repo with a v2 and v3 version, it will typically look like t
5382
```json
5483
{
5584
"extends": "@sanity/semantic-release-preset",
56-
"branches": ["main", {"name": "v3", "channel": "studio-v3", "prerelease": "v3-studio"}]
85+
"branches": ["main", {"name": "studio-v2", "channel": "studio-v2", "range": "1.x.x"}]
5786
}
5887
```
5988

60-
This assumes that the v2 version lives on `main` and the v3 versions livs on `v3`.
61-
The v3 version will be a pre-release using `studio-v3` as npm tag, and `v3-studio` version suffix.
89+
This assumes that the v2 version lives on `studio-v2` branch and the v3 version livs on `main`.
90+
The v2 version will be constrained to a version range and use `studio-v2` as npm tag.
91+
The v3 version will be release with `latest` npm tag.
6292

6393
### 6. Test workflow and remove `--dry-run`
6494

@@ -69,6 +99,7 @@ workflow for the V3-branch and check "Release new version".
6999

70100
Inspect the workflow logs to see the version that will be used for the release.
71101
If it is ok, remove the `--dry-run` flag from the workflow to perform a real release.
102+
72103
If the version is not what you expected, you might have to perform some
73104
[troubleshooting](https://semantic-release.gitbook.io/semantic-release/support/troubleshooting).
74105

@@ -82,11 +113,8 @@ Now run:
82113
This will run semantic-release in dry-run mode (no git push or npm publish) and show everything that would
83114
go into a release.
84115

85-
## What does it do?
86-
87-
Adds opinionated config and dependencies used by the Ecosystem team on Sanity to develop using
88-
semantic-release driven workflow on Github.
116+
#### Note on "notable commits"
117+
As configured, semantic-release will not consider commits starting with `docs:` or `chore:` as notable.
118+
If you only have non-notable commits since the last release, semantic-release will not create a new version.
89119

90-
- Adds husky and related files and dependencies to do pre-commit checks
91-
- Adds semantic-release and preset dependencies to automate npm & Github releases
92-
- Updates README.md with some standard texts
120+
Therefore, chores or doc updates that should be considered notable should use `fix(chore):` or `fix(docs):` suffix instead.

src/presets/semver-workflow.ts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,7 @@ async function addDevDependencies(options: InjectOptions) {
6565
semantic-release preset injected.
6666
6767
Please confer
68-
https://github.com/sanity-io/plugin-kit/blob/main/docs/semver-workflow.md
68+
https://github.com/sanity-io/plugin-kit/blob/main/docs/semver-workflow.md#manual-steps-after-inject
6969
to finalize configuration for this preset.
7070
`.trim()
7171
)

0 commit comments

Comments
 (0)