feat(dynamic-import): support Astro v6 - v7

[FrancescoCiannavei]

Hello, remember me?
A few months ago I asked if I could open this pr and contribute, unfortunately after a few commits I got stuck and forgot about the thing, recently I had a project that needed the package to be updated and so I remembered, in the meanwhile astro v7 got released, I also covered it in the pr.
The issue was #171.

What I did

This lets astro-dynamic-import work with Astro 6 and 7. The integration itself didn't need any code changes, it already works on both. What's here is the wider peer dependency range, the test harness moving to Astro 6, and the assertions loosened a bit so they pass on both 6 and 7.

7 files:

File	Change
packages/dynamic-import/package.json	peer dep 4 || 5 => 4 || 5 || 6 || 7
package.json	root dev astro ^5.16.1 => ^6.1.6
tests/package.json	@astrojs/node 9 => 10, astro 5 => 6
tests/fixtures/dynamic-import/package.json	astro 5 => 6
tests/dynamic-import.test.ts	assertions updated so the same file passes on 6 and 7
pnpm-lock.yaml	lockfile for the Astro 6 harness
.gitignore	ignore .DS_Store (MacOs junk)

Supported Astro versions

Astro	Supported	Verified here	Notes
4	yes (peer dep)	no	inherited, didn't re-test it
5	yes (peer dep)	no	the previous baseline, nothing known to be broken
6	yes	12/12 tests + a real site	build inlines the component's script now, assertions updated for that
7	yes	12/12 tests + a real 7.0.6 site	works fine, some caveats below

Astro 7 caveats

Nothing here is a problem with the integration itself, just stuff I hit along the way:

• Astro 7's dev server rewrites named CSS colors to hex (paleturquoise => #afeeee) while 6 keeps the name. Only the dev assertions cared, they accept either form now.
• CI runs on Astro 6, not 7. The harness shares one astro install across every package (tests/utils.ts imports astro directly), and moving it to 7 breaks two unrelated packages: server-only-modules uses the astro/entrypoints/prerender export that 7 removed, and emotion-extract checks a class hash that changed. Getting the whole repo onto 7 felt like its own PR, so the harness stays on 6, the newest version where the full passes.
• If you want to check 7 yourself: bump astro to 7 in both tests/package.json and tests/fixtures/dynamic-import/package.json, pnpm install, then pnpm test dynamic-import.test.ts. Bumping only the harness leaves the fixture on 6 and crashes with Cannot read properties of undefined (reading 'enabled'), which looks bad but is just the version skew, not the integration.

Testing

pnpm test dynamic-import.test.ts passes 12/12 on Astro 6, and 12/12 on Astro 7 with the local bump from the caveats section. pnpm install --frozen-lockfile passes too.

I also ran a real Astro 7.0.6 site through both build and dev:

• build inlines only the picked component's script and scopes its style (#afeeee and #fff8dc)
• dev serves the script externally (?astro&type=script)
• nothing leaks scripts or styles across pages, including the request-time Math.random() "CMS" case

[changeset-bot]

⚠️ No Changeset found

Latest commit: e2ad53f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[FrancescoCiannavei]

I'm working on fixing the error

[FrancescoCiannavei]

Fyi the last commit was 60% - 80% written by claude, but it looks good to me, I feel like I need to disclose that part.

The windows failure looks unrelated to the PR, the failing test is node-websocket.test.ts => build => performs upgrade, which timed out at 511ms against the 500ms budget, that block has had since #108. The websocket fixture still runs astro 5, so with the per-fixture resolution it exercises the exact same path as the last green run. The dev variant of the same test passed in 391ms in the same job and dynamic-import itself passed 12/12 on all platforms, windows included.

Would you be open to bumping that build block's timeout from 500 to 1k, matching the dev block? Happy to include it here or in a separate PR.
Otherwise a rerun should do it.

[lilnasy]

yes, feel free to include it

[FrancescoCiannavei]

The timeout bump didn't help, windows failed again, at 1014ms against the 1000ms budget (previously 511ms against 500ms), the timeout was never the problem, standalone() calls listen() without awaiting it:

server.server.listen(port, host);   // standalone.ts:27
return { server, done: server.closed() };

startServer() returns while the bind is still pending and beforeAll finishes before the port exists. The first test connects, gets refused, and hangs, it registers only onopen/onmessage, and since node's WebSocket is EventTarget based the unhandled error event doesn't throw. Nothing settles the promise, so the test consumes whatever budget it's given, a 30s timeout would fail at 30s.

These are the logs that showed it:

10:03:14.7340152  stdout | node-websocket.test.ts > build > performs upgrade
10:03:14.7342133  [astro-node-websocket] Server listening on http://localhost:4321
10:03:15.7377261  × build > performs upgrade 1014ms

That "Server listening" line comes from log-listening-on.ts, which awaits the listening event before printing, so it marks the real bind, and it lands about 10ms after the test had already started.

I reverted the timeout to 500.

build > performs upgrade does around 7ms of work. dev > performs upgrade is 208ms locally and around 380ms on windows because dev compiles the route on first request, while build serves prebuilt output, 500 already had 70x headroom. Leaving it at 1000 would encode a wrong belief about the test, so I reverted it.

The unawaited listen() and missing onerror both predate this PR, timeout: 500 dates back to 418ee0b, and the websocket fixture resolves astro 5.16.1 both before and after my harness change. I did check the one thing that could plausibly be mine: the harness now loads two Astro majors in a single worker, so I measured whether the extra heap was delaying the bind, heap tripled, bind delay didn't move.

I couldn't determine what changed to make it start failing now, CI only runs on pull_request so there's no main baseline, and the last green run's logs are past retention.

[FrancescoCiannavei]

@lilnasy as of last commit the pr is ready for you to review and merge it.
I remember you saying you were busy lately, please take your time, I am in no rush.
For any questions I'm here.

[lilnasy]

Thanks, will try to take a look this week

[lilnasy]

This looks great! I would like to exclusively support Astro 7, I'll make that change in a follow up PR before release. Thanks!