[db] Fix duplicate calls to recreate tables on startup

[bholmesdev]

Changes

This simplifies table initialization by pulling table creation and seeding out of Vite.

Before

• Buildtime: astro:db is loaded
• Runtime: astro:db calls recreateTables with top-level await.
• Runtime: astro:db calls seedLocal() with top-level await. Seed files are loaded as Vite modules.

After

• Buildtime: astro:db is loaded
• Buildtime: recreateTables is called.
• Buildtime: seeding is called. Seed files are loaded using esbuild, the same as our db execute CLI command.

Changes

• Move seeding from the Vite runtime to a buildtime call using esbuild
• Remove special astro:db:seed virtual module used for deduping. This dramatically simplifies the DB vite plugin by removing the resolveId special case.
• Remove eager reloading for seed files. This code included an invalidateModule() call on the astro:db module, which introduced a race condition when unit testing. This removal means that, if you edit the seed file, we no longer "eagerly" re-seed the database; you still need to refresh your dev server to trigger a seed. We still have eager seeding on dev startup though, so SQLite inspectors should still have a nice experience.
• Delete seed-local.ts
• Move queries.js out of runtime and into core. Less code shipped to SSR!

Testing

Ensure all tests still pass. Also tested against @astrojs/web-vitals to ensure tests pass when this merges.

Docs

N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: 3b014fd

The changes in this PR will be included in the next version bump.

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

[Princesseuh]

Buildtime: seeding is called. Seed files are loaded using esbuild, the same as our db execute CLI command.

Does this mean you can't access things from the Vite part anymore inside seeding? ex: content collections using astro:content or astro:assets etc.

[bholmesdev]

@Princesseuh This is correct, though this was in an inconsistent state before as it did not work with db execute. We can restore that functionality if we spin up a vite dev server similar to the content collection config. Do you consider that a blocker? Do you know if users are relying on astro content for local db?

[Princesseuh]

@Princesseuh This is correct, though this was in an inconsistent state before as it did not work with db execute. We can restore that functionality if we spin up a vite dev server similar to the content collection config. Do you consider that a blocker? Do you know if users are relying on astro content for local db?

I am myself 😅 Both for astro:content and astro:assets. I'm not sure for content, but I would imagine that putting image URLs from getImage in the db would be something somewhat likely

[delucis]

Approving in principle as #NWTWWHB — happy to let you figure out what makes sense w/r/t availability of other virtual modules. Seems nice to do if possible (maybe in a follow-up PR?)

Spotted a bit of unused code which I’m not sure why linting isn’t flagging?