Skip to content

fix(cli): load task and tool metadata without resolving Vite - #3187

Open
jasonkuhrt wants to merge 1 commit into
voidzero-dev:mainfrom
jasonkuhrt:metadata-only-config-loading
Open

jasonkuhrt wants to merge 1 commit into
voidzero-dev:mainfrom
jasonkuhrt:metadata-only-config-loading

Conversation

@jasonkuhrt

Copy link
Copy Markdown

Summary

Reading task or tool settings from vite.config.* currently runs Vite's full config-resolution pipeline. A plugin's config or configResolved hook can therefore fail a metadata read, and Vite resolves dev-server options that the metadata consumer never uses.

Issue #2845 traced this path to the read of pnpm's node_modules/.modules.yaml. Automatic task input tracking originally made changes to installation timestamps and machine-specific paths invalidate cached tasks. Current main already contains vite-task#850, which fingerprints only the manifest's existence. This change removes the unnecessary resolution path itself.

Use Vite's public loadConfigFromFile inside the existing metadata-resolution guard. Preserve config discovery, workspace traversal, the loaded config path, async/function configs, and the existing build / development evaluation defaults. Preserve NODE_ENV initialization, including Vite Task's tracked environment lookup. Return the user config instead of a fully resolved Vite config.

The public resolveConfig export and dev/build/preview paths retain full resolution. Metadata fields supplied by plugin hooks will no longer be populated on this path.

Validation

  • pnpm -F vite-plus build: passed, including JS/declarations and the native binding.
  • vp test run packages/cli: 90 files passed; 2,370 tests passed, one skipped.
  • pnpm test:unit: 113 files passed; 2,557 tests passed, one skipped.
  • vp check and pnpm tsgo: passed.
  • Eight new cases cover skipped plugin hooks, equal metadata across equivalent pnpm manifest states, async-config environment defaults, missing configs, workspace traversal, and full resolution after metadata loading.
  • The two central regressions fail with the original loader and pass with this change. Full-resolution controls still run plugin hooks and include each installation's virtual-store path in server.fs.allow.

Oxlint and Oxfmt need a separate Oxc change: their shared loader calls the public resolveConfig export directly and does not use this internal helper.

Refs #2845

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant