Revert "docs(ipc): switch vite-proposal to internal-plugin approach"

This reverts commit 16a3e78.

Author: wan9chi

docs/runner-task-ipc/vite-proposal.md

@@ -43,11 +43,7 @@ Vite Task needs the Vite process to communicate two things:
 
 ## Cases && Proposed Changes
 
-The proposal has three pieces:
-
-1. Add `@voidzero-dev/vite-task-client` as a dependency.
-2. Ship an internal plugin (`vite-task-plugin`) inside Vite that calls the client at the right points. The plugin is gated by the same env var Vite Task sets, so it's fully inert when Vite runs outside Vite Task.
-3. Add non-public plugin hooks where existing ones aren't enough. The hooks are designed in a generic shape (any plugin could use them) with no stability guarantee for now, ready to be promoted to public hooks later if they prove stable.
+We want to add a small dependency `@voidzero-dev/vite-task-client` to Vite that lets it talk to Vite Task at runtime. Vite calls into the client at the relevant code paths to declare "ignore this path as an input/output" or "fetch these envs from Vite Task". The calls **are no-ops when Vite runs outside Vite Task**.
 
 ### 1. Reading envs according to `envPrefix`
 
@@ -64,7 +60,10 @@ This task config duplicates `envPrefix`. The two configs currently have to be ma
 
 **Proposed Changes**:
 
-`configResolved` fires after `loadEnv` has already read envs by prefix, so this case needs a new internal hook. We add `loadEnvPrefixed`, which fires inside `loadEnv` before the prefix-read loop:
+Add a call to `vite-task-client`'s `fetchEnvs` **before reading the envs matching `envPrefix`**. If Vite is running outside Vite Task, this calls is a no-op. If Vite is running inside Vite Task, it does two things:
+
+- It tells Vite Task which envs are relevant to the build, so they **become part of the cache fingerprint**.
+- It **populates `process.env`** with those envs, so Vite can see them.
 
 ```diff
 --- a/packages/vite/src/node/env.ts
@@ -73,17 +72,11 @@ This task config duplicates `envPrefix`. The two configs currently have to be ma
    const parsed = Object.fromEntries(...);
    for (const [key, value] of Object.entries(parsed))
      if (prefixes.some(p => key.startsWith(p))) env[key] = value;
-+  // New non-public hook. Fires synchronously so plugins can inject
-+  // prefix-matched envs into process.env before the loop below reads it.
-+  await callPluginHook('loadEnvPrefixed', prefixes);
++  for (const prefix of prefixes) fetchEnvs(`${prefix}*`, { tracked: true });
    for (const key in process.env)
      if (prefixes.some(p => key.startsWith(p))) env[key] = process.env[key];
 ```
 
-`vite-task-plugin` handles `loadEnvPrefixed` by calling `fetchEnvs(`${prefix}\*`, { tracked: true })` for each prefix. When Vite runs inside Vite Task this populates `process.env` with the matching values (so the loop below reads them) and tells Vite Task which envs to fingerprint. When Vite runs outside Vite Task the call is a no-op.
-
-The hook is generic in shape: any plugin could use it to inject envs by prefix during `loadEnv`. It stays non-public until the shape settles, then can be promoted to a public hook.
-
 ### 2. Pre-bundling deps in `cacheDir`
 
 Vite's dep optimizer reads metadata from and writes pre-bundled deps into [`cacheDir`](https://vite.dev/config/shared-options#cachedir) (default `node_modules/.vite/`).
@@ -102,7 +95,19 @@ And `cacheDir` is user-configurable, so the path in this config has to match wha
 
 **Proposed Changes**:
 
-`vite-task-plugin` handles this in the existing `configResolved` hook (no new Vite hook needed). By the time the dep optimizer reads or writes inside `config.cacheDir`, Vite Task already knows to ignore the directory.
+Add two calls **right after resolving `depsCacheDir`**. If Vite is running outside Vite Task, these calls are no-ops. If Vite is running inside Vite Task, they do two things:
+
+- They tell Vite Task to **not treat reads in this directory as inputs**.
+- They tell Vite Task to **not treat writes in this directory as outputs**.
+
+```diff
+--- a/packages/vite/src/node/optimizer/index.ts
++++ b/packages/vite/src/node/optimizer/index.ts
+@@ loadCachedDepOptimizationMetadata(environment, force) {
+   const depsCacheDir = getDepsCacheDir(environment);
++  ignoreInput(depsCacheDir);
++  ignoreOutput(depsCacheDir);
+```
 
 ### 3. Cleaning `outDir` before writing the bundle
 
@@ -112,7 +117,16 @@ Before writing the bundle, Vite calls [`emptyDir(outDir)`](https://github.com/vi
 
 **Proposed Changes**:
 
-Same as case 2: `vite-task-plugin` calls `ignoreInput(config.build.outDir)` in `configResolved`. The bundle write is still tracked as an output, which is correct. No new Vite hook needed.
+Add a call **before `emptyDir`**. If Vite is running outside Vite Task, this call is a no-op. If Vite is running inside Vite Task, it tells Vite Task to **not treat reads in this directory as inputs**.
+
+```diff
+--- a/packages/vite/src/node/plugins/prepareOutDir.ts
++++ b/packages/vite/src/node/plugins/prepareOutDir.ts
+@@ prepareOutDir(outDirs, emptyOutDir, environment) {
+   for (const outDir of outDirs) {
++    ignoreInput(outDir);
+     if (emptyOutDir !== false && fs.existsSync(outDir)) emptyDir(outDir, ...);
+```
 
 ### 4. Globbing files in `import.meta.glob`
 
@@ -139,30 +153,6 @@ When called inside Vite Task, Vite Task does the globbing itself and returns the
    ).filter(...).sort()
 ```
 
-### The plugin
-
-```ts
-// vite/src/node/plugins/viteTaskPlugin.ts
-import { fetchEnvs, ignoreInput, ignoreOutput } from '@voidzero-dev/vite-task-client';
-
-export const viteTaskPlugin = {
-  name: 'vite:task',
-
-  configResolved(config) {
-    // Cases 2 and 3.
-    ignoreInput(config.cacheDir);
-    ignoreOutput(config.cacheDir);
-    ignoreInput(config.build.outDir);
-  },
-
-  // New non-public hook (case 1).
-  loadEnvPrefixed(prefixes) {
-    for (const prefix of prefixes) fetchEnvs(`${prefix}*`, { tracked: true });
-  },
-};
-```
-
-The plugin is added to Vite's built-in plugin list and only activates when Vite Task spawns Vite (gated by the same env var that the wrapper uses to find `node_client`).
 
 ## Details of `@voidzero-dev/vite-task-client` package
 
@@ -230,5 +220,6 @@ Two examples of what could come next:
   - **Logic locality.** Each call belongs next to the Vite code that owns its path; patching from outside puts them somewhere else.
   - Users with a self-installed Vite (not the Vite+ bundled one) would get no benefit.
 
-- **Ship the plugin and any new hooks as public Vite API from day one.**
-  - Vite would commit to long-term API stability for hooks (like `loadEnvPrefixed`) before their shape has settled. Internal-with-no-stability lets us iterate first; promotion to public can happen later if a hook proves stable.
+- **Implement this in a Vite plugin**
+  - The plugin doesn't have the enough hooks to cover all cases (fetch envs for `envPrefix`).
+  - Enhancing the plugin API to cover all cases would be a much bigger impact on Vite.