Repository navigation
fix(auth): load auth.ts through Vite in builds and void prepare - #611
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex review |
🚀 Deploying Preview to Cloudflare 🚀Preview URL: https://fix-auth-config-build-loader-void-cloud.voidzero-docs.workers.dev (commit 106d132)This URL reflects your latest Preview deploymentPreview Deployments by commit
|
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Dev already loads auth.ts through a Vite module runner, but `vite build`, `void prepare` and the CLI commands that run it still used a plain Node `import()`. An auth.ts that imports a project file without an extension (`import './db'`) or through a Vite alias (`@schema/...`) failed there with "Cannot find module", even though dev worked. Builds and CLI commands now evaluate auth.ts once with Vite's `runnerImport`, so imports resolve as in dev. A build passes its own resolved aliases and `tsconfigPaths`; `void prepare` reads them from the app's Vite config. The loader also accepted `export const auth` or `export const config`, but the Worker only imports the default export, so the generated schema and the runtime could disagree. It now requires a default export and says to use `export default defineAuth(...)`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`void prepare`, `void gen` and `void db generate` read only the raw
vite.config to find aliases for auth.ts. Aliases that plugins add in
their `config()` hook were missing, such as Void's own `@schema`, so an
auth.ts with `import { ... } from '@Schema'` failed with "Cannot find
module '@Schema'" there, while dev and build worked.
These commands now resolve the app's Vite config with its plugins and
use its aliases. When the dev server has no auth config environment, the
migration fallback uses the server's resolved aliases too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
b1e2ab9 to
7e8d32a
Compare
`void prepare`, `void gen` and `void db generate` loaded the app's vite.config to find aliases for auth.ts. Evaluating it constructs the app's plugins, and Void's plugin writes generated files and Cloudflare config when constructed, so preparing types could change the project. `void prepare` must not boot the app's Vite. These commands now evaluate auth.ts without the app's Vite config. Imports still resolve without extensions, through tsconfig `paths`, and through Void's own `@schema` alias. An alias set only in vite.config resolves in dev and builds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Fixed in 106d132 on #611, which this PR is stacked on. |
Auto-merge was disabled for another pull request in the stack
Problem
Dev loads
auth.tsthrough a Vite module runner.vite buildandvoid prepare(alsovoid gen/void db) still used Node's ownimport(). So anauth.tswith a normal import failed there, while dev worked:The loader also took
export const auth/export const config. The Worker only imports the default export, so the schema could be built from a config the runtime never reads.Fix
viteAuthConfigImporter(root, mode, resolve)runsauth.tsonce with Vite'srunnerImport.projectAuthConfigImporter(root)is for commands outside Vite. It resolves the app's vite config with its plugins (resolveConfig, serve, development), only when anauth.tsexists. Aliases that plugins add inconfig(), such as Void's@schema, are included.devAuthConfigImporter(server)always gives an importer: the auth config environment, or else a runner with the dev server's resolved aliases.loadVoidAuthConfignow needs an importer and accepts only a default export.Tests
void preparein a plainnodechild process (Vitest's runner would hide the bug):auth.tsimports an extensionless file, an alias from vite.config, and@schemaadded by a plugin'sconfig()hook. All three fields reach the generated schema.routingPluginbuildStartwith a resolved build config that has an alias. Same check.Choices to check
resolve.aliasandresolve.tsconfigPathsare passed on to the runner, not plugins. A plugin that resolves imports inresolveIdwithout an alias is not applied toauth.tsoutside dev.auth.tsnow resolve their vite config (with pluginconfig()/configResolved()hooks) duringvoid prepare. That adds about 1s, and an error in the vite config or a plugin hook now stops prepare.🤖 Generated with Claude Code