diff --git a/.changeset/README.md b/.changeset/README.md index e5b6d8d..8c7e753 100644 --- a/.changeset/README.md +++ b/.changeset/README.md @@ -6,3 +6,243 @@ find the full documentation for it [in our repository](https://github.com/change We have a quick list of common questions to get you started engaging with this project in [our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md) + +You will be responsible for writing a **changeset** for your Astro PR. This is a Markdown file that states: + +- which repository has changed +- the kind of change according to [Astro's semantic versioning](https://docs.astro.build/en/upgrade-astro/#semantic-versioning) +- a message describing the change that will be publicly displayed on the repo's CHANGELOG + +```md title=".changeset/my-super-cool-changeset.md" wrap +--- +"astro": patch +--- + +Fixes unexpected `undefined` value when calling an action from the client without a return value +``` + +You can generate a changeset using the `pnpm changeset` command, which will prompt you for the necessary information and create a randomly-named file in the `.changeset` folder. You can then edit the generated file to add more detail, or write your changeset from scratch. + +## Format + +Begin your changeset message with **a present tense verb** that completes a sentence in the style of: "This PR . . ." or "This contribution ..." + +- Adds +- Removes +- Fixes +- Updates +- Refactors +- Improves +- Deprecates + +Finish the introductory sentence with a message focusing on what has changed **about the codebase** (not what your feature itself does) that is meaningful to a **user** of Astro. It is usually more helpful to describe the change **as someone building an Astro site will experience it**, instead of describing **how you fixed it** or **what the code in the PR does**: + +```markdown title="changeset.md" del={2} ins={5} +// What the code now does +Logs helpful errors if content is invalid + +// The nature of the change to the Astro code base +Adds logging for content collections configuration errors. +``` + +You may then include additional paragraphs if necessary to describe the change in more detail. This may not be needed for a small bug fix, but is often helpful if the reader must make a change to their own code, or needs to understand how the change might affect them. + +The level of detail of a changeset depends on the type of change (e.g. `patch` vs `minor`, breaking or not, only affects integration authors etc.) You may also use [`

` - `

` Markdown headings](#using-markdown-section-headings) to break your longer content into sections. + +:::tip[Don't hide the good stuff in the changeset!] +CHANGELOGS are often read only once, when someone is updating to the latest version of a package. Documentation is a constant reference that will be revisited and consulted frequently. + +Make sure that the helpful explanations and examples for your fellow developers in both your changeset and your PR description are captured in the actual feature documentation, too! +::: + +### Patch updates + +These updates are often fixes, refactors or other small improvements. They are typically not user-facing, and do not require someone to update their own project code. + +Verbs like "fixes" and "refactors" are helpful to let readers know this is an internal or implementation change that they do not need to worry about. At the same time, these messages are helpful to someone who is interested in keeping up with small changes to the codebase. + +Often one line is enough to describe your change meaningfully to an Astro user: + +```md title="my-patch-changeset.md" wrap +--- +"astro": patch +--- + +Fixes a bug where the toolbar audit would incorrectly flag images as above the fold +``` + +```md title="my-patch-changeset.md" wrap +--- +"astro": patch +--- + +Refactors internal handling of styles and scripts for content collections to improve build performance +``` + +```md title="my-patch-changeset.md" wrap +--- +"astro": patch +--- + +Updates the `HTMLAttributes` type exported from `astro` to allow data attributes +``` + +These do not need to be full sentences and do not need end punctuation unless you write multiple sentences. + +:::tip[Help your reader figure out if this is change important to them] +Even though these are small changes described by very short sentences, they still need to communicate a lot! + +Check that you have clearly stated not just **what has changed** but also **who needs to know**. If your reader can identify that a change is important to them, they can always seek out further information if they need to know more. +::: + +#### Tips and Examples + +For a great changeset message: + +Include the specific API changed (using inline code highlighting as appropriate) when your change might not be easy to identify so that your reader can easily tell whether it's something they are using and need to care about: + +> Improves automatic fallbacks generation +> +> vs +> +> ✅ Improves automatic `fallbacks` generation **for the experimental Fonts API** + +When the specific API change is not user-facing (e.g. a type not publicly exposed) and/or your reader will not recognize it by name, describe the use case or end result that will be meaningful to the reader instead: + +> Adds `| (string & {})` for better autocomplete of `App.SessionData` +> +> vs +> +> ✅ Improves autocompletion for session keys + +### New features + +Begin your changeset with "Adds" to alert readers that there is something new and mention the names of any new items (options, functions) that have been added directly in the first sentence: + +```md title="my-minor-changeset.md" wrap +--- +"astro": minor +--- + +Adds a new `flamethrow` view transitions animation + + +``` + +Additionally, describe what people are now able to do because of these additions that they could not before. + +The changeset is an opportunity to call people's attention to new things they might wish to try in their Astro project, and may include a code example showing basic usage of the new feature: + +````md wrap title="my-minor-changeset.md" +--- +"astro": minor +--- + +Adds a new, optional property `timeout` for the `client:idle` directive + +This value allows you to specify a maximum time to wait, in milliseconds, before hydrating a UI framework component, even if the page is not yet done with its initial load. + +This means you can delay hydration for lower-priority UI elements with more control to ensure your element is interactive within a specified time frame. + +``` +