@merkur/svelte 0.47.2 → 1.0.3

package/README.md

@@ -38,8 +38,42 @@ To check out [live demo](https://merkur.js.org/demo) and [docs](https://merkur.j
 
 Contribute to this project via [Pull-Requests](https://github.com/mjancarik/merkur/pulls).
 
-We are following [Conventional Commits Specification](https://www.conventionalcommits.org/en/v1.0.0/#summary). To simplify the commit process, you can use `npm run commit` command. It opens an interactive interface, which should help you with commit message composition.
+We are using [Changesets](https://github.com/changesets/changesets) for versioning and releasing. To add a changeset describing your changes, run `npm run changeset`.
 
+> **Note:** The release process is documented **only** in this root README. Any per-package README sections that still describe a Lerna/Conventional Commits–based release flow are outdated and should be ignored in favour of the instructions below.
+
+### Changeset format
+
+Each changeset file (`.changeset/*.md`) must follow this structure:
+
+**Frontmatter** — standard Changesets YAML listing affected package names and bump types (`patch`, `minor`, `major`).
+
+**First line after frontmatter** — a single brief sentence summarising the change. No heading, no bold, no trailing bullet — just a plain declarative sentence. This section is not required but helps to quickly understand the change when browsing the changesets.
+
+**Body** — three bullet points in this exact order, with no blank lines between them:
+
+- **What** One or more sentences describing what changed: which APIs, files, or behaviours were added, removed, or fixed. Make sublists if needed to break down complex changes, but keep each bullet point as a single paragraph.
+- **Why** One or more sentences explaining the motivation: why the change was necessary or beneficial.
+- **How** Migration steps for consumers or contributors. If no action is required, write exactly: `Nothing.`
+
+Additional rules:
+- Each bullet is a single paragraph — no nested lists, no code blocks inside a bullet.
+- Do not use headings (`##`, `###`) inside the body.
+- Code symbols (function names, paths, package names) use backtick inline code.
+
+Example:
+
+```markdown
+---
+"@merkur/example": minor
+---
+
+Add `createFoo` helper for simplified widget initialisation.
+
+- **What** New `createFoo(options)` export in `@merkur/example` wraps the low-level `initFoo` call and applies sensible defaults for `name` and `version`.
+- **Why** Every project was duplicating the same boilerplate to call `initFoo`; centralising it reduces setup friction and ensures consistent defaults.
+- **How** Replace direct `initFoo` calls with `createFoo({ name, version })`. The returned object is API-compatible, so no further changes are needed.
+```
 
 ### Release
 
@@ -48,32 +82,43 @@ To release a version you must have the right permissions, please contact one of
 
 #### Regular version release
 
-To do a regular release, in the root of the monorepo run:
+To do a regular release, from the `master` branch with no uncommitted changes, run:
 
 ```
 npm run release
 ```
 
-#### RC (preversion) release
-
-1. From the specific package directory, use this `lerna version` command to bump package versions:
-  ```
-  npx lerna version <preminor | prepatch | prerelease> --no-git-tag-version --no-push
-  // prerelease increments the pre* version's last number, e.g. v0.44.0-rc.0 => v0.44.0-rc.1
-  ```
-  - alternatively, manually change the version in the package's `package.json` and in `lerna.json`, and run `npm install` from the root of the monorepo.
-2. Restore all files not related to the package you intend to release. These files should remain:
-  - the package's own `package.json`
-  - `lerna.json` (otherwise lerna will stop incrementing the pre-version's number, for some reason)
-  - `package-lock.json`
-3. Commit the changes (must still be a conventional commit. Suggested: `chore(release): publish`). 
-4. Tag the commit with the version (e.g. `v0.44.0-rc.0`). 
-5. Push the commit to the repo.
-6. Push the tag to the repo: `git push origin tag <tagname>` (e.g. `git push origin tag v0.44.0-rc.0`).
-
-The packages are released from a GitHub Action that is triggered when a new version tag is pushed to the repository.
-
-Before the actual release, it's safer to return all version numbers to the last stable version. Another option is to release from a separate branch, so your feature branch stays clean.
+This runs `release:prepare` (applies pending changesets, bumps versions, updates `package-lock.json`) followed by `release:push` (commits, tags, and pushes to the repository).
+
+Packages are published from a GitHub Action triggered when a new version tag is pushed.
+
+#### RC (pre-release) release
+
+1. Enter pre-release mode (only needs to be done once per RC cycle):
+   ```
+   npm run release:next:init
+   ```
+   This sets pre-release mode to `rc`, so subsequent version bumps produce `rc` versions (e.g. `v0.44.0-rc.0`).
+
+2. Add a changeset describing your changes:
+   ```
+   npm run changeset
+   ```
+
+3. Bump versions and push the RC release:
+   ```
+   npm run release
+   ```
+   Repeat steps 2–3 for each subsequent RC iteration (e.g. `rc.0 → rc.1`).
+
+4. When ready to graduate to a stable release, exit pre-release mode and prepare the final version:
+   ```
+   npm run release:graduate
+   ```
+   Then push with:
+   ```
+   npm run release:push
+   ```
 
 ---
 

package/package.json

@@ -1,13 +1,12 @@
 {
   "name": "@merkur/svelte",
-  "version": "0.47.2",
+  "version": "1.0.3",
   "description": "Collection of helpers to aid with Svelte integration to @merkur",
   "scripts": {
     "test": "echo 'Tests pass.'",
     "test:es:version": "echo 'Tests pass.'",
     "build": "rollup -c rollup.config.mjs",
-    "dev": "rollup -c rollup.config.mjs -w",
-    "postpublish": "node ../../utils/restoreLatestTag.mjs"
+    "dev": "rollup -c rollup.config.mjs -w"
   },
   "exports": {
     "./entries/client.js": "./entries/client.js",
@@ -53,6 +52,5 @@
     "esbuild-svelte": "^0.8.0",
     "svelte": "^3.59.2",
     "svelte-loader": "^3.2.0"
-  },
-  "gitHead": "1f8dd906f352a28828785d33791a8a4129836f35"
+  }
 }

package/LICENSE

@@ -1,7 +0,0 @@
-Copyright 2020 Miroslav Jancarik jancarikmiroslav@gmail.com
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.