[pull] main from withastro:main - #694
Merged
Merged
Conversation
…17664) Co-authored-by: ematipico <estoppa@cloudflare.com>
#17757) Co-authored-by: factory[bot] <factory[bot]@users.noreply.github.com>
…en server address is null (#17758) Co-authored-by: factory[bot] <factory[bot]@users.noreply.github.com> Co-authored-by: ematipico <estoppa@cloudflare.com>
…17744) (#17754) In Docker containers, PID namespaces reset on restart, so the new `astro dev` process often inherits the same PID the old one had. The lock file from the previous run persists, and the process detects itself as the "already running" server. Add a self-PID guard to `isLockFileProcessAlive()`: if the lock file's PID matches `process.pid`, treat it as stale immediately. The current process cannot be the server recorded in the lock file because it hasn't started one yet. Co-authored-by: factory[bot] <factory[bot]@users.noreply.github.com>
* Require changesets in triage fix and PR-writer skills * Update .agents/skills/astro-pr-writer/SKILL.md * Update .agents/skills/astro-pr-writer/SKILL.md * Update .agents/skills/triage/fix.md
…tibility (#17756) npm v11+ warns about packages with unapproved install scripts, and npm v12 will make this a hard failure. Astro depends on esbuild which has a postinstall script that downloads platform-specific binaries. Add `allowScripts` for esbuild to all example package.json files and add `ensureNpmScriptsAllowed()` to create-astro to pre-approve esbuild in package.json before running `npm install`. Fixes #17745 Co-authored-by: factory[bot] <factory[bot]@users.noreply.github.com> Co-authored-by: Matthew Phillips <matthew@matthewphillips.info>
* fix: rebuild module imports after content entry deletion (#17707) * test: exercise debounced module-import trigger on delete/clear/clearAll (#17707) Prior tests called writeModuleImports() explicitly right after delete/clear, which forced the rebuild to run synchronously regardless of whether the new #writeModulesImportsDebounced() calls inside delete()/clear()/clearAll() were wired correctly. Reverting those three trigger lines still passed all existing assertions. Rewrite the delete/clear tests to rely on waitUntilSaveComplete() alone, add a clearAll()-specific test, and add a rename test (delete(oldId) + set(newId)) matching the issue's actual reported scenario. Verified: reverting the three trigger lines makes the delete/clear/clearAll tests fail; restoring them makes all pass. * fix: return early after writing an empty content-modules.mjs The zero-size branch in writeModuleImports() fell through to the generator below it, writing the file twice on every call where #moduleImports ends up empty (e.g. after deleting the last deferred-render entry) -- first 'export default new Map();', then a second, differently-formatted empty-map write. That path only became reachable once #moduleImports could shrink back to zero, which this PR introduces. Add the missing return, matching the pattern review comment. Also note in the changeset that addModuleImport() callers without a backing deferredRender entry no longer survive a write, now that #moduleImports is fully derived state.
…17750) * fix(transitions): do not re-create media inside persisted subtrees reifyMediaElements() (#17603) runs after transition:persist elements from the old document have been moved into the new body, so it also replaced the live <audio>/<video> nodes carried over from the previous page. Those nodes were never parsed by DOMParser and are not inert; re-creating them resets currentTime/paused and drops listeners and framework refs, which breaks persistent players on every navigation. Skip media whose nearest [data-astro-transition-persist] host is one of the persisted elements. Media inside a persist container that appears for the first time on the new page still get reified, so #17601 stays fixed for that case. * fix(transitions): skip exactly the media that were live before the swap Collect the <video>/<audio> nodes of the old body before the swap and skip those in reifyMediaElements(). This is precise by construction: a node that was live and is still in the new body got there through transition:persist — at any nesting depth, including persist containers nested inside a persisted one that have no counterpart on the new page, and the attribute placed on the media element itself. Media parsed from the new document are never in the set and still get reified (#17601 stays fixed). * test(e2e): persisted media keep DOM identity across ClientRouter navigation Two view-transitions e2e tests that fail on main and pass with the fix: an expando set on the persisted <video> before navigation must still be there afterwards — for transition:persist on the media element itself, and for media inside an inner persist container that has no counterpart on the next page (it travels with its matched outer container). The existing '<video> can persist' test only asserts that currentTime grows, which a freshly re-created autoplaying element also satisfies — that is why the regression went unnoticed. Also spells out in swap-functions.ts why the liveMedia snapshot is sufficient. * chore: re-sync pull request head * more user-centric, less technical ;-) * Update persisted-media-keep-identity.md --------- Co-authored-by: Martin Trapp <94928215+martrapp@users.noreply.github.com>
…ning (#17770) Co-authored-by: factory[bot] <factory[bot]@users.noreply.github.com>
…key (#17719) * fix(session): validate session cookie value as UUID before using as storage key * fix(session): validate session IDs before cleanup --------- Co-authored-by: Matthew Phillips <matthew@matthewphillips.info>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )