Repository navigation
[i18nIgnore] Transpile Starlight packages - #3572
Merged
Merged
Conversation
🦋 Changeset detectedLatest commit: 491b69c The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for astro-starlight ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Member
Author
|
Thanks for thorough review considering the amount of changes 🙌 Added a changeset for the main change, altho not sure I'm super happy with the wording but didn't find a better way to phrase it for now. |
delucis
previously approved these changes
Sep 1, 2026
delucis
approved these changes
Sep 2, 2026
Merged
HiDeoo
added a commit
to HiDeoo/starlight
that referenced
this pull request
Sep 2, 2026
* main: [i18nIgnore] Transpile Starlight packages (withastro#3572) i18n(ru): update translations (withastro#4170) [ci] release (withastro#4169) Fix hidden heading anchor links (withastro#4167) perf: optimize route and sidebar lookups (withastro#4148) chore: add benchmarks (withastro#4157)
|
Woohoo! Thanks for all the work on this 🙌 |
dadezzz
pushed a commit
to dadezzz/university_notes
that referenced
this pull request
Sep 6, 2026
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [@astrojs/starlight](https://starlight.astro.build) ([source](https://github.com/withastro/starlight/tree/HEAD/packages/starlight)) | [`0.41.11` → `0.42.0`](https://renovatebot.com/diffs/npm/@astrojs%2fstarlight/0.41.11/0.42.0) |  |  | --- ### Release Notes <details> <summary>withastro/starlight (@​astrojs/starlight)</summary> ### [`v0.42.0`](https://github.com/withastro/starlight/blob/HEAD/packages/starlight/CHANGELOG.md#0420) [Compare Source](https://github.com/withastro/starlight/compare/@astrojs/starlight@0.41.11...@astrojs/starlight@0.42.0) ##### Minor Changes - [#​3572](withastro/starlight#3572) [`292fb17`](withastro/starlight@292fb17) Thanks [@​HiDeoo](https://github.com/HiDeoo)! - Distributes package as JavaScript files with dedicated type declaration files instead of TypeScript source files. - [#​4121](withastro/starlight#4121) [`2623ae6`](withastro/starlight@2623ae6) Thanks [@​delucis](https://github.com/delucis)! - Simplifies markup for Starlight’s mobile menu toggle **⚠️ Potentially breaking change:** If you use a theme plugin, custom styles, or component overrides targeting the `MobileMenuToggle` button or `PageFrame` components, you may need to adjust these for the new markup. The button is no longer wrapped in a `<starlight-menu-button>` custom element and no longer uses the `aria-expanded` attribute. Instead, you can use the `.sl-menu-button` class name to target the button and the `:popover-open` pseudo-class to style the menu open state specifically. In the following example, custom styles for the menu button are updated for the new approach: ```diff - starlight-menu-button button { + .sl-menu-button { color: var(--sl-color-text); } - starlight-menu-button[aria-expanded='true'] button { + .sl-menu-button:has(~ :popover-open) { color: var(--sl-color-text-accent-high); } ``` See [`MobileMenuToggle.astro`](https://github.com/withastro/starlight/blob/main/packages/starlight/components/MobileMenuToggle.astro) and [`PageFrame.astro`](https://github.com/withastro/starlight/blob/main/packages/starlight/components/PageFrame.astro) on GitHub for the full source code of the updated components. - [#​3572](withastro/starlight#3572) [`292fb17`](withastro/starlight@292fb17) Thanks [@​HiDeoo](https://github.com/HiDeoo)! - Removes the `tagline` configuration option, which was never used. If your configuration included a `tagline` option, you can safely remove it without any replacement. - [#​4134](withastro/starlight#4134) [`6135f01`](withastro/starlight@6135f01) Thanks [@​HiDeoo](https://github.com/HiDeoo)! - Updates internal `@astrojs/mdx`, `@astrojs/markdown-satteri`, and `satteri` dependencies.⚠️ **BREAKING CHANGE:** The following minimum versions are now required: - `astro` v7.2.10 or later - `@astrojs/markdown-satteri` 0.4.0 or later (if you use it) - `@astrojs/markdown-remark` 7.3.0 or later (if you use it) Please update Starlight and Astro together: ```sh npx @astrojs/upgrade ``` - [#​4121](withastro/starlight#4121) [`2623ae6`](withastro/starlight@2623ae6) Thanks [@​delucis](https://github.com/delucis)! - Refactors Starlight’s mobile menu toggle to work when JavaScript fails or is disabled⚠️ **BREAKING CHANGE:** This release drops official support for Chromium-based browsers prior to version 116 (released August 2023), Safari-based browsers prior to version 17.0 (released September 2023), and Firefox prior to version 125 (released April 2024). You can find a list of currently supported browsers and their versions using this [browserslist query](https://browsersl.ist/#q=%3E+0.5%25%2C+not+dead%2C+Chrome+%3E%3D+116%2C+Edge+%3E%3D+116%2C+Firefox+%3E%3D+125%2C+Safari+%3E%3D+17.0%2C+iOS+%3E%3D+17.0%2C+not+op_mini+all). This change also removes the `data-mobile-menu-expanded` attribute, which was previously added to `<body>` while the mobile menu is open. If you have custom code that was depending on this attribute, you will need to update it to use a new selector to check if the mobile menu is open. In the following example, a custom background colour for the site header while the menu is open is updated for the new approach: ```diff - [data-mobile-menu-expanded] header { + body:has(sl-sidebar-pane:popover-open) header { background-color: var(--sl-color-bg); } ``` </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC42NS4yIiwidXBkYXRlZEluVmVyIjoiNDQuNjUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
keyurgolani
added a commit
to PersonalClaw/personalclaw.dev
that referenced
this pull request
Sep 8, 2026
…t stops the build Dependabot's grouped npm bump (#61) carries `@astrojs/starlight` 0.41.10 -> 0.42.0, and 0.42.0 removes the top-level `tagline` option outright. Starlight validates its config strictly, so an unrecognised key is a hard error rather than a warning: `astro sync` — the first thing all three site jobs run — dies with [AstroUserError] Invalid config passed to starlight integration Hint: Unrecognized key: "tagline" which reds "Static build and publication contract", "Lighthouse performance budgets" and "Browser, accessibility, privacy, and visual regression" together, plus the Vercel deployment. Three red jobs and one failed deploy, all one unrecognised key. The upstream entry (withastro/starlight#3572) is explicit about the migration: "Removes the `tagline` configuration option, which was never used" — no replacement, safe to delete. So the sentence this repo had been setting there ("Generated from the tagged source this site was built from.") rendered NOWHERE on 0.41 either. Deleting the key changes no pixel, and the comment in its place says that, plus where the fact belongs if it is worth surfacing: page content, not a key the framework ignored. Verified in the order that makes it evidence rather than hope: reproduced the CI failure locally FIRST (`astro sync` exit 1, same "Unrecognized key" hint) against the bumped lockfile, then applied the deletion and re-ran. - `astro sync` exit 0; `npm run build` 43 pages, exit 0. - `npm run test:static` exit 0 — 5 marketing routes + 33 docs pages + registry index + 2 blog + 1 compare validated, 117 research cross-links resolved, registry render contract verified. - `npx playwright test` **139 passed** — including the visual-regression suite against the committed darwin baselines, so the `lucide-react` 1.37 -> 1.41 and astro/react bumps riding along change no rendered pixel. That was the live risk in taking this group. - `node scripts/lighthouse-audit.mjs` exit 0 — performance/accessibility/best-practices/seo 100 on every audited route. `npm audit --audit-level=moderate` exits 1 with 6 vulnerabilities (1 moderate, 5 high: browserslist, fast-uri, js-yaml, nanoid, postcss, undici). Measured against main's lockfile under the same command: byte-for-byte the same six. This bump introduces none of them — they are pre-existing transitive debt and want their own change, so they are reported here rather than folded in silently or used as a reason to hold the fix. <!-- no-visual-delta --> **Why no screenshot:** the deleted key rendered nothing on either version — upstream removed it as "never used" — and the visual-regression suite passing against unchanged baselines is the stronger evidence that the page is identical. Closes #61 Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
keyurgolani
added a commit
to PersonalClaw/personalclaw.dev
that referenced
this pull request
Sep 22, 2026
…t stops the build Dependabot's grouped npm bump (#61) carries `@astrojs/starlight` 0.41.10 -> 0.42.0, and 0.42.0 removes the top-level `tagline` option outright. Starlight validates its config strictly, so an unrecognised key is a hard error rather than a warning: `astro sync` — the first thing all three site jobs run — dies with [AstroUserError] Invalid config passed to starlight integration Hint: Unrecognized key: "tagline" which reds "Static build and publication contract", "Lighthouse performance budgets" and "Browser, accessibility, privacy, and visual regression" together, plus the Vercel deployment. Three red jobs and one failed deploy, all one unrecognised key. The upstream entry (withastro/starlight#3572) is explicit about the migration: "Removes the `tagline` configuration option, which was never used" — no replacement, safe to delete. So the sentence this repo had been setting there ("Generated from the tagged source this site was built from.") rendered NOWHERE on 0.41 either. Deleting the key changes no pixel, and the comment in its place says that, plus where the fact belongs if it is worth surfacing: page content, not a key the framework ignored. Verified in the order that makes it evidence rather than hope: reproduced the CI failure locally FIRST (`astro sync` exit 1, same "Unrecognized key" hint) against the bumped lockfile, then applied the deletion and re-ran. - `astro sync` exit 0; `npm run build` 43 pages, exit 0. - `npm run test:static` exit 0 — 5 marketing routes + 33 docs pages + registry index + 2 blog + 1 compare validated, 117 research cross-links resolved, registry render contract verified. - `npx playwright test` **139 passed** — including the visual-regression suite against the committed darwin baselines, so the `lucide-react` 1.37 -> 1.41 and astro/react bumps riding along change no rendered pixel. That was the live risk in taking this group. - `node scripts/lighthouse-audit.mjs` exit 0 — performance/accessibility/best-practices/seo 100 on every audited route. `npm audit --audit-level=moderate` exits 1 with 6 vulnerabilities (1 moderate, 5 high: browserslist, fast-uri, js-yaml, nanoid, postcss, undici). Measured against main's lockfile under the same command: byte-for-byte the same six. This bump introduces none of them — they are pre-existing transitive debt and want their own change, so they are reported here rather than folded in silently or used as a reason to hold the fix. <!-- no-visual-delta --> **Why no screenshot:** the deleted key rendered nothing on either version — upstream removed it as "never used" — and the visual-regression suite passing against unchanged baselines is the stronger evidence that the page is identical. Closes #61 Signed-off-by: Keyur Golani <keyurrgolani@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Description
This PR is an early draft (not yet ready for review) that transpiles Starlight packages from TypeScript to JavaScript to avoid publishing TypeScript which is not a recommended or even supported practice.
Approach
Multiples approaches are usually available when it comes to transpiling in monorepos and keeping the flexibility of working with TypeScript source code in development.
Custom export condition was one of the first options considered, and would probably be the most long-term solution, but we cannot currently use them for Starlight. For the
docs/site to properly consume custom conditions in development, in Astro, such conditions would need to be defined in the Astro configuration using theviteproperty, altho Starlight itself is imported in such configuration so it's a chicken-and-egg problem right now. There is a world in the future where we would be able to run Astro usingnode --conditionsdirectly, and Vite automatically picks up those conditions, but this requires some changes in Node that are not yet available.Considering the above, this PR relies on
pnpmand specifically on the fact thatpnpmautomatically overrides some fields inpackage.jsonfiles when packages are published withpnpm publishby the one defined in thepackage.jsonpublishConfigproperty. In the case of Starlight, we maintain 2exportsfields: one for development (pointing to the TypeScript source files like it is today) and one for production (pointing to the transpiled JavaScript files).How to test
When getting closer to a reviewable state, some pre-release packages will probably be published to test the changes in a real-world scenario.
In the meantime, you can test the changes locally using a different Starlight project outside of the monorepo, e.g. one setup using
pnpm create astro --template starlight.Remaining tasks
pnpm changeset publishusespnpm publishunder the hood (it probably does, aspackage-manager-detectoris used when actually publishing to figure out the package manager but need to double check) (explained here:If you are using pnpm as a package manager, this automatically detects it and uses pnpm publish instead.)