Thanks to all the other contributors who helped make Astro 5.8 possible, including: Adam Matthiesen, Alan, Alexey Zimarev, Angelo Verlain Shema, Ariel K, Armand Philippot, Augusto César Perin, Bugo,

aka planning to publish a Starlight v1 Work in progress pre v1 ✅ Completed ✅ i18next support (PR #1923) — already announced and should be merged soon ✅ Improved simpler sidebar config that autogenerates from file data (PR #1874) ✅ <LinkButton> (PR #1784) ✅ Sidebar state persistence (added that to the Q3 breakdown document as a deliverable for myself — I think the process would be identifying what/when to persist/restore (make a document/checklist for this), either help an existing PR or make a new one and add tests for this) ✅ Full SSR support (PR #1255) — kind of low value from a general perspective, attractive to a small fraction of users, but maybe still worth stabilising before v1 in case it requires anything breaking.

Discussions Let's go through some discussion ideas and see whether any should be promoted to "Issues" to solve in/with docs! 11133: document dev server shortcuts 6205: adding TS tabs to JS code examples 10073: consistent code snippets 11165: update client-side scripts 11309: content collections caching explanation 11189: should Upgrade Astro guide / older docs be more prominent? 10912: add polar.sh to e-commerce guide

As a reference documentation, nice! I’d imagine that beginners would like more handholding, so a „guide“ start to finish (for releasing a npm package) would lower the bar The doc https://docs.astro.build/en/reference/publish-to-npm/ is linked but it seems to be specific to Astro components. Most things probably apply but some information has to be found between the lines. For example, that one should ship ESM-only isn’t written down but can be derived from the package.json. That could be made more obvious. Generalizing the language would also make it more obvious that you can use this doc for content loaders, too. This doc or the „publish to npm“ is missing the important bit that you should also publish TypeScript types with your package For the „name“ of the loader, if you have opinions on how the naming scheme should be (like we had with gatsby-source-xyz) write it down Mention that you can put multiple loaders into one NPM package, not just one We both used environment variables for loading common options. This tip can also go into the docs While https://docs.astro.build/en/reference/content-loader-reference/#loader-api shows all available loader APIs it doesn’t prominently give recommendations on what to use/what is required and what not. Establish best practices here, because the examples in the earlier parts of the doc e.g. don’t show the „parseData()“ function while I’d argue that it would be very important to always run it. It’s mentioned in a paragraph of DataEntry but can easily be missed No information on how to handle network errors or throw errors Highlight more that store.set() id must be unique

When Starlight renders a page in your documentation, it first creates a route data object to represent what is on that page. This guide explains how route data is generated, how it is used, and how you can customize it to modify Starlight’s default behavior. What is route data? Starlight route data is an object constructed for each page of your site by combining the following parts of your project: The Starlight configuration in astro.config.mjs The content and frontmatter of the current page For example, the route data includes a siteTitle property with a value based on the title option in your Starlight configuration and a toc property generated from headings in the content for the current page.

Tutorial https://github.com/withastro/blog-tutorial-demo/ [x] PR 32 - update code for v5 [x] update content-collections branch based on new 6.4 unit Sidebar changes still to come [x] - separate experimental and legacy flags into their own section (from config ref) [x] - CLI advanced section gets its own page in API reference section as “Programmatic Astro API (Experimental)” [x] - move "develop and build" content into new page (from install and setup)

Sidebars :ghost: Participate in PR 9890 Test with the Deployment preview link Visit the deploy link on as many devices/browsers as possible. Share your observations in the text chat! Leave important comments on the PR for follow up (e.g. accessibility/performance issues) Sidebar content changes still to come ??? separate experimental and legacy flags into their own section (from config ref)

A glowing pink neon sign with the Astro logo that reads "ON THE AIR" with "Talking and Doc'ing" underneath. The podcaster version of our square, smiley-faced mascot Houston, wearing earphones and in front of a microphone sits underneath, on a purple galaxy background.

Docs sidebar project site Astro Docs card sort activity from last week

Topic: Astro Docs Navigation Goal: Review the past and current state of docs navigation; have good discussions and ideas Today we'll be looking at the overall navigation experience in Astro docs, which consists of two parts: the navigation infrastructure and implementation itself the organization of content into navigable items and sub-items Links:

Questions from Kapa AI -- actionable for docs? How do I import an Astro component's Props type? In my components, I always export the Props type. But now I want to get the Props type of <Code /> from astro:components. That component doesn't export its Props type. Is there any way I can access it? Yes, you can access the Props type of another component even if it doesn't export it directly. Astro provides a utility called ComponentProps for this purpose. You can use it to reference the Props type of another component. Here's how you can do it: import type { ComponentProps } from 'astro/types'; import Code from 'astro:components/Code.astro'; type CodeProps = ComponentProps<typeof Code>; In the above code, ComponentProps is imported from astro/types and used to reference the Props type of the <Code /> component. This feature was added in astro@4.3.0.

Updating Recipe Cards update schema for recipes with a new optional property for the card's title, so we can update the page title to something longer update each recipe with this property, and copy the page title rewrite the page title to be a nicer standalone page title update the existing components (RecipeLinks and RecipeNav) to use this new property fall back to the title if the new property isn’t set

I know that we can access user's IP address in Astro using Astro.clientAddress value but this would only work in .astro pages. // your-ip.astro --- const detectedIp = Astro.clientAddress; --- <h1> Your IP: {{ detectedIP }}

I'm trying to convert the following API from Next.js to Astro.build: import type { NextApiRequest, NextApiResponse } from "next"; import prisma from "lib/prisma"; export default async function handler( req: NextApiRequest, res: NextApiResponse ) { try {

I'm new to astro and a little stuck on what seems to be a simple thing. I need to share fetched data in layout (kind of like protected route) to all page components. I am using SSR with Node adapter and for the life of me can't figure out how to do it. I have tried nanostores / named slots hoping props can be passed like that. RIght now the next options I am considering is cookies (doesn't feel right) and custom node-cache like described here In react terms, this is what I would like do: <ContextProvider / Store Setup Component> // Fetch some data and setup either store or context provider <Route 1 /> // Has access to data and not having to re-fetch <Route 2 /> // Has access to data and not having to re-fetch ....

A family friend is trying to make a blog with a paywall and I figured it would be a good portfolio project to help them. Although I am still pretty new to astro I really love the dev experience and have used it for some small projects and it seems like the ideal fit for a blog. But with the wrinkle of a paywall, user login, and mailing list to keep users up to date with new posts, does this move the project out of Astro's wheelhouse? Sorry if this is a noobish question Answer 1 Sure, you could still statically render most pages on the site while using middleware to validate the user: https://docs.astro.build/en/guides/middleware/. You can use Astro's SSR and middleware to create an authorized/paywall only pages. Answer 2 I am new to Astro, but not dev. And I’ve primarily done backend. I’ve thought about this but haven’t tried it yet . If you were willing to take on something new and interesting look at Cloudflare workers or some of the other serverless systems.

I have an astrojs project with the following structure. pages/ |- index.astro |- blog/index.astro |- blog/[slug].astro |- blog/[page].astro Since the project is not static, I render in SSR mode. Since I am a beginner in this subject, I learn everything by doing and trying. Most things look and work pretty well now, but I just can't seem to get the pagination done. The examples I've seen are all prepared in SSG mode because they always include getStaticPaths. However, if you use getStaticPaths in SSR mode, you'll get some kind of warning that it doesn't work and is excluded.

Using Astro, I have a layout file: /src/layouts/MdxLayout.astro where I try to set allowed components Button and Link to be rendered if passed in from a page file. --- import BaseLayout from '@/layouts/Base/BaseLayout.astro'; import Button from '@/components/Button/Button'; import Link from "@/components/Link/Link"; --- <BaseLayout components={{ Button: Button, Link: Link }}> <slot />

I am trying to load an unknown amount of webfonts in Astro. function getFonts() { return ` ${global.font .map((item) => { return `@font-face { font-family: ${item.name}; src: url(${item.url2}) format('woff2'), url(${item.url1}) format('woff');

How to generate actuall static HTML pages from astro that I will be able to open without any CDN. Just to open index.html from file system. Now astro includes / at begining of each link that doesn't work in my case. instead of <link rel="stylesheet" href="/_astro/hoisted.83c691aa.css" /> do <link rel="stylesheet" href="_astro/hoisted.83c691aa.css" /> and hrefs to other static HTML files