astro

Changes A dev toolbar app's UI is destroyed on the first client-side navigation and never restored — silently, with no error and still . assigns , which replaces rather than appends, discarding whatever the app rendered into its canvas. The canvas reconnects on every navigation. Nothing rebuilds it — sits behind the guard, so never runs a second time. Fix:** write the style once in the constructor and drop , which had no other job. Only is affected. projects through a `DevToolbarTooltippatchthird-party app content survives a client-side navigationpackages/astro/e2e/dev-toolbar.test.tsdev-toolbarview-transition-abtoHaveCount: Expected 1, Received 0`), passes again once restored. Docs

Changes in answers "does this path point at a file with an extension?" but its regex required a slash immediately before the filename (). Because of the leading slash, a bare filename with no directory segment was never matched: The fix anchors the match to the start of the string or a slash: . This is strictly additive: it only changes results for inputs lacking a leading path segment (incorrect becomes correct ). Every path beginning with and every genuinely extension-less input is unchanged. Why it matters decides trailing-slash behavior and static-file handling, including (called on a base-stripped request path that can be a bare filename), and / endpoint trailing-slash decisions. A bare asset filename could previously be misclassified as extension-less. Testing Added a block to (the function previously had no tests) covering directory paths, bare filenames, multi-dot names, extension-less paths, and a trailing dot. Local checks, all green: build, (70 pass / 0 fail), biome format/lint/check, typecheck, and (patch bump for , cascading to ). Docs No user-facing docs change; internal helper behavior fix. Changeset included ().

What this fixes Fixes #17793. Using Zod's on an object containing an Astro field causes the Content Layer to throw a runtime during content processing: The schema itself is valid Zod and parses the content successfully the failure happens afterward, when Astro processes image references. Root cause In , the collection accessor's handler walks the parsed with neotraverse's and calls to strip the from image strings. That is an in-place mutation. When the user's schema uses , Zod returns a frozen object (and frozen nested objects), so mutating it directly throws. The fix Before traversing/mutating, produce a deep mutable clone with , run the traversal over the clone, and store the clone in the entry. The user's original (possibly frozen) object is never written to. This matches the direction suggested in the issue "operate on a mutable copy rather than mutate the object returned by the user's schema." is safe here because the content-layer data is plain, devalue-serializable data at this point (it is about to be serialized to disk). The image-prefixing schema-parse path is untouched. Tests Added a regression test in : "handles frozen data from a schema without throwing (issue #17793)." It builds a frozen object (with a nested frozen object) containing image-prefixed values, then asserts that: does not throw, the stored data has the image prefixes stripped, the user's original frozen object is left untouched, the paths are recorded correctly. unit tests: 11/11 pass. All content-collections unit tests: 42/42 pass, no regressions. : no errors ( is a Node 22 global). A changeset is included.