vite-plus 0.3.1 → 0.3.3

package/docs/guide/troubleshooting.md

@@ -15,18 +15,28 @@ Vite+ expects modern upstream tool versions.
 
 If you are migrating an existing project and it still depends on older Vite or Vitest versions, upgrade those first before adopting Vite+.
 
-Run `vp toolchain` to show the versions from the local Vite+ package.
-Run `vp toolchain --global` to show the versions from the global Vite+ release.
+Run `vp toolchain` to show the versions from the local Vite+ package. Run `vp toolchain --global` to show the versions from the global Vite+ release.
 
 ## `vp check` does not run type-aware lint rules or type checks
 
 - Confirm that `lint.options.typeAware` and `lint.options.typeCheck` are enabled in `vite.config.ts`
 - Check whether your `tsconfig.json` still uses `compilerOptions.baseUrl`
 
-The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`.
-`vp migrate` and `vp lint --init` try to run the `vp dlx @andrewbranch/ts5to6 --fixBaseUrl .`
-fix before enabling type-aware linting. If that fix fails or is declined, Vite+
-skips `typeAware` and `typeCheck`.
+The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`. `vp migrate` and `vp lint --init` try to run the `vp dlx @andrewbranch/ts5to6 --fixBaseUrl .` fix before enabling type-aware linting. If that fix fails or is declined, Vite+ skips `typeAware` and `typeCheck`.
+
+## Nested lint or format config is not applied
+
+Vite+ does not currently support nested lint or format configuration. When running `vp lint`, `vp fmt`, or `vp check` from the workspace root, do not rely on configs in subdirectories or on `lint` and `fmt` blocks in package-level `vite.config.ts` files to override the root settings.
+
+Keep lint and format settings in the root `vite.config.ts`. Use [`lint.overrides`](/guide/monorepo#root-config-with-overrides) and [`fmt.overrides`](/guide/monorepo#format-overrides) for file- or package-specific settings. You can also [import configuration objects](/guide/monorepo#composing-configuration-files) into the root config to keep settings in separate files.
+
+For IDE integration, we have `disableNestedConfig` and `fmt.disableNestedConfig` config to disable nested lint and format configs and keep editor behavior aligned with the root Vite+ config. See [IDE Integration](/guide/ide-integration) for setup instructions for your editor.
+
+We're holding off on nested config support for now. Some of the factors we're considering are how implicit config discovery affects the predictability of linting and formatting, what context AI agents need to understand the settings that apply, and the potential performance cost of finding and loading multiple configs. At the same time, we recognize that keeping package-specific context close to the code may have benefits. The use cases we've heard so far haven't given us a strong enough reason to commit to those semantics. Waiting leaves room to add support later, and we'd like to hear why your project needs nested configs, especially where root-level overrides fall short.
+
+Do you need nested configs? [Share your use case and opinion on GitHub](https://github.com/voidzero-dev/vite-plus/discussions/2669), including your project structure, the reason why you want them and whether root-level overrides meet your needs.
+
+We sincerely hope to hear your feedback. This will help us decide whether to improve the current situation in the future.
 
 ## VS Code extension does not read `vite.config.ts`
 
@@ -62,8 +72,7 @@ If `vp staged` fails or your pre-commit hook does not run:
 - if status shows `Preference: disabled (local)`, re-enable with `vp hooks enable`
 - check whether hooks were skipped intentionally through `VP_GIT_HOOKS=0`
 
-To stop hooks in this clone without deleting project policy files, run `vp hooks disable`.
-See the [Commit hooks guide](/guide/commit-hooks) for the full workflow.
+To stop hooks in this clone without deleting project policy files, run `vp hooks disable`. See the [Commit hooks guide](/guide/commit-hooks) for the full workflow.
 
 A minimal staged config looks like this:
 

package/docs/guide/upgrade-project.md

@@ -0,0 +1,61 @@
+# Update Vite+
+
+Updating `vite-plus` and its related project dependencies. To upgrade the global `vp` binary, see [Upgrading Vite+](/guide/upgrade).
+
+## Update with Migrate
+
+The recommended way to update a project is to use `vp migrate`, which keeps the toolchain dependencies aligned.
+
+After updating the project's `vite-plus` dependency, run the local CLI to align the toolchain versions:
+
+```bash
+./node_modules/.bin/vp migrate
+```
+
+If your global CLI is newer than the project's version, running `vp migrate` upgrades the project to that global version instead:
+
+```bash
+vp migrate
+```
+
+On a project that is already on Vite+, migrate does a toolchain version upgrade only: it re-pins `vite-plus`, the `vite` -> `@voidzero-dev/vite-plus-core` alias, and the `vitest` pin to the versions bundled with the CLI running the migration, across every workspace package. It skips the first-time setup steps (git hooks, editor and agent files, lint migration), so a version bump does not re-touch things you already configured. Pass `--full` to also run that setup.
+
+## Manually Updating
+
+Update `vite-plus` and the `vite` alias to `@voidzero-dev/vite-plus-core` together, keeping the core version aligned with `vite-plus`. Update these entries wherever they are declared in your workspace, including overrides or catalogs, then install dependencies to refresh the lockfile. Also [update the Vitest pin](#updating-the-vitest-pin) to match the bundled version.
+
+Without the global CLI, run the `vp` commands on this page through your package manager, for example `pnpm exec vp toolchain vitest`.
+
+### Updating the Vitest Pin
+
+If you migrated with `vp migrate`, your project pins `vitest` to an exact version so the whole project shares a single Vitest copy with the bundled `vp test` runner. The pin lives in your package manager's override block:
+
+- **npm / Bun:** a `vitest` entry under `overrides` in `package.json`
+- **Yarn:** a `vitest` entry under `resolutions` in `package.json`
+- **pnpm:** a `vitest@*` entry under `overrides` in `pnpm-workspace.yaml`. If your `package.json` already has a `pnpm` field, the entry lives under `pnpm.overrides` in `package.json` instead. pnpm ignores `pnpm-workspace.yaml` overrides when `package.json` defines `pnpm.overrides`.
+
+A Vite+ release can bump the bundled Vitest. Because that pin also applies to `vite-plus`'s own `vitest` dependency, an out-of-date pin keeps installing the previous runner even after you upgrade `vite-plus` — splitting Vitest's internals (mocks, `expect`, runner state) between the pinned copy and the one `vp test` loads.
+
+After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
+
+```bash
+vp toolchain vitest
+```
+
+Then set the `vitest` override to that exact version and reinstall dependencies.
+
+::: details Why pnpm overrides use `@*`
+Under pnpm the managed keys use an explicit `@*` range (`vite@*`, `vitest@*`). pnpm applies an override by replacing the declared spec on every manifest, importer manifests included. A bare key matches any spec, including `catalog:`. The `@*` range keeps the override on the semver ranges that transitive and peer declarations use, and leaves `catalog:` references intact. `vp up` therefore no longer rewrites them to a concrete version.
+:::
+
+## Preview Builds
+
+After [installing a preview build of the global CLI](/guide/upgrade#global-vp-preview), run migrate in the project to move its local `vite-plus` onto the same build:
+
+```bash
+vp migrate
+```
+
+Migrate writes the bridge registry to `.npmrc`. For Yarn Berry, it writes the registry to `.yarnrc.yml`. It pins `vite-plus` and the `vite` alias to the matching `0.0.0-commit.<sha>` version. The `vite` alias points to `@voidzero-dev/vite-plus-core`. Commit the registry line if the project CI must test the preview.
+
+After the install, run `vp toolchain` to show the selected versions. After testing, set `vite-plus` to `latest`. Remove the bridge `registry` line from `.npmrc` or `.yarnrc.yml`. Then run `vp install`.

package/docs/guide/upgrade.md

@@ -1,13 +1,13 @@
 # Upgrading Vite+
 
-Use `vp upgrade` to update the global `vp` binary, and use Vite+'s package management commands to update the local `vite-plus` package in a project.
+Use `vp upgrade` to update the global `vp` binary. To update the local `vite-plus` package in a project, see [Update Vite+](/guide/upgrade-project).
 
 ## Overview
 
 There are two parts to upgrading Vite+:
 
 - The global `vp` command installed on your machine
-- The local `vite-plus` package used by an individual project
+- The [local `vite-plus` package](/guide/upgrade-project) used by an individual project
 
 You can upgrade both of them independently.
 
@@ -22,20 +22,18 @@ vp toolchain vite rolldown oxc
 vp toolchain --json
 ```
 
-The command uses the local `vite-plus` package when the project has one. Use
-`--global` to show the release for the global `vp` command:
+The command uses the local `vite-plus` package when the project has one. Use `--global` to show the release for the global `vp` command:
 
 ```bash
 vp toolchain --global
 ```
 
-`vp why <package>` shows the dependency graph from the package manager. It
-cannot show code bundled into `@voidzero-dev/vite-plus-core`. It also cannot
-show engines compiled into Vite+. Use `vp toolchain` to show those versions and
-relationships.
+`vp why <package>` shows the dependency graph from the package manager. It cannot show code bundled into `@voidzero-dev/vite-plus-core`. It also cannot show engines compiled into Vite+. Use `vp toolchain` to show those versions and relationships.
 
 ## Global `vp`
 
+Update the global CLI with:
+
 ```bash
 vp upgrade                        # upgrade to the latest version
 vp upgrade --check                # check for updates without installing
@@ -45,27 +43,14 @@ vp upgrade --registry <registry>  # use a custom npm registry
 
 ### Move an Existing Install to the Split Directory Layout
 
-Vite+ 0.3.0 is the first release that supports the split directory layout.
-Vite+ 0.2.x and earlier use the single-root layout for fresh installs and
-upgrades.
+Vite+ 0.3.0 is the first release that supports the split directory layout. Vite+ 0.2.x and earlier use the single-root layout for fresh installs and upgrades.
 
-`vp upgrade` keeps an existing default install in `~/.vite-plus` on Unix or
-`%USERPROFILE%\.vite-plus` on Windows. The command upgrades the CLI in that
-directory. It does not move the install to the split platform directories. You
-can continue to use the existing layout.
+`vp upgrade` keeps an existing default install in `~/.vite-plus` on Unix or `%USERPROFILE%\.vite-plus` on Windows. The command upgrades the CLI in that directory. It does not move the install to the split platform directories. You can continue to use the existing layout.
 
-To use the split layout now, remove the existing install. Then install Vite+
-again. Run `vp implode` in a shell that uses the current install. The command
-removes the generated environment file and shell profile entries. It does not
-unset directory variables in the current shell. Unset all Vite+ directory
-variables before you run the installer. This can include values from an earlier
-preview environment file. Alternatively, start a new shell after `vp implode`.
-Then run the installer in the new shell.
+To use the split layout now, remove the existing install. Then install Vite+ again. Run `vp implode` in a shell that uses the current install. The command removes the generated environment file and shell profile entries. It does not unset directory variables in the current shell. Unset all Vite+ directory variables before you run the installer. This can include values from an earlier preview environment file. Alternatively, start a new shell after `vp implode`. Then run the installer in the new shell.
 
 ::: warning
-`vp implode` removes all Vite+-managed Node.js runtimes, global packages,
-configuration, and caches. Keep the existing layout if you do not want to
-recreate that data.
+`vp implode` removes all Vite+-managed Node.js runtimes, global packages, configuration, and caches. Keep the existing layout if you do not want to recreate that data.
 :::
 
 ```bash
@@ -82,11 +67,7 @@ Remove-Item Env:\VP_HOME, Env:\VP_DATA_DIR, Env:\VP_BIN_DIR, Env:\VP_CACHE_DIR -
 irm https://vite.plus/ps1 | iex
 ```
 
-Also remove persistent definitions of `VP_HOME`, `VP_DATA_DIR`, `VP_BIN_DIR`,
-and `VP_CACHE_DIR` from your shell profile or system environment. A fresh
-install uses `VP_HOME` or a complete `VP_*_DIR` group that remains set.
-`VP_HOME` selects the single-root layout. If you install Vite+ 0.2.x or earlier,
-the installer also uses this layout. The installer prints a notice.
+Also remove persistent definitions of `VP_HOME`, `VP_DATA_DIR`, `VP_BIN_DIR`, and `VP_CACHE_DIR` from your shell profile or system environment. A fresh install uses `VP_HOME` or a complete `VP_*_DIR` group that remains set. `VP_HOME` selects the single-root layout. If you install Vite+ 0.2.x or earlier, the installer also uses this layout. The installer prints a notice.
 
 ### Rollback
 
@@ -98,35 +79,17 @@ vp upgrade --rollback
 
 Older versions are pruned automatically after each upgrade. The active version and the previous version are always kept, so a rollback target is never removed.
 
-## Local `vite-plus`
+### Homebrew
 
-The recommended way to upgrade an existing Vite+ project is `vp migrate`:
+Homebrew owns its installed binary and JavaScript package. Update them with:
 
 ```bash
-vp migrate
+brew upgrade vite-plus
 ```
 
-On a project that is already on Vite+, migrate does a toolchain version upgrade only: it re-pins `vite-plus`, the `vite` -> `@voidzero-dev/vite-plus-core` alias, and the `vitest` pin to the versions the global `vp` now bundles, across every workspace package. It skips the first-time setup steps (git hooks, editor and agent files, lint migration), so a version bump does not re-touch things you already configured. Pass `--full` to also run that setup.
-
-### Updating the Vitest Pin
-
-If you migrated with `vp migrate`, your project pins `vitest` to an exact version so the whole project shares a single Vitest copy with the bundled `vp test` runner. The pin lives in your package manager's override block:
-
-- **npm / Bun:** a `vitest` entry under `overrides` in `package.json`
-- **Yarn:** a `vitest` entry under `resolutions` in `package.json`
-- **pnpm:** a `vitest@*` entry under `overrides` in `pnpm-workspace.yaml`. If your `package.json` already has a `pnpm` field, the entry lives under `pnpm.overrides` in `package.json` instead. pnpm ignores `pnpm-workspace.yaml` overrides when `package.json` defines `pnpm.overrides`.
+`vp upgrade` detects Homebrew installations and directs you to this command without downloading or installing another version. This also applies to `--force`, a specific version, and `--rollback`. Use Homebrew to manage these installations.
 
-Under pnpm the managed keys use an explicit `@*` range (`vite@*`, `vitest@*`). pnpm applies an override by replacing the declared spec on every manifest, importer manifests included. A bare key matches any spec, including `catalog:`. The `@*` range keeps the override on the semver ranges that transitive and peer declarations use, and leaves `catalog:` references intact. `vp up` therefore no longer rewrites them to a concrete version.
-
-A Vite+ release can bump the bundled Vitest. Because that pin also applies to `vite-plus`'s own `vitest` dependency, an out-of-date pin keeps installing the previous runner even after you upgrade `vite-plus` — splitting Vitest's internals (mocks, `expect`, runner state) between the pinned copy and the one `vp test` loads.
-
-After upgrading `vite-plus`, re-pin `vitest` to the version Vite+ now bundles. Check that version with:
-
-```bash
-vp toolchain vitest
-```
-
-Then set the `vitest` override to that exact version, or rerun `vp migrate` to update the pin for you.
+`vp upgrade --check` directs you to `brew outdated vite-plus`. Automatic npm update checks and notices are disabled for Homebrew installations.
 
 ## Preview Builds
 
@@ -160,12 +123,4 @@ The installer uses the registry bridge to resolve the ref to a `0.0.0-commit.<sh
 
 ### Local `vite-plus` Preview
 
-After installing the preview global CLI above, run migrate in the project to move its local `vite-plus` onto the same build:
-
-```bash
-vp migrate
-```
-
-Migrate writes the bridge registry to `.npmrc`. For Yarn Berry, it writes the registry to `.yarnrc.yml`. It pins `vite-plus` and the `vite` alias to the matching `0.0.0-commit.<sha>` version. The `vite` alias points to `@voidzero-dev/vite-plus-core`. Commit the registry line if the project CI must test the preview.
-
-After the install, run `vp toolchain` to show the selected versions. After testing, set `vite-plus` to `latest`. Remove the bridge `registry` line from `.npmrc` or `.yarnrc.yml`. Then run `vp install`.
+To use the same preview in a project, follow [Update Vite+](/guide/upgrade-project#preview-builds).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vite-plus",
-  "version": "0.3.1",
+  "version": "0.3.3",
   "description": "The Unified Toolchain for the Web",
   "homepage": "https://viteplus.dev/guide",
   "bugs": {
@@ -69,6 +69,15 @@
       "types": "./dist/lint.d.ts",
       "import": "./dist/lint.js"
     },
+    "./lint/plugins": {
+      "types": "./dist/lint-plugins.d.ts",
+      "import": "./dist/lint-plugins.js",
+      "require": "./dist/lint-plugins.cjs"
+    },
+    "./lint/plugins-dev": {
+      "types": "./dist/lint-plugins-dev.d.ts",
+      "default": "./dist/lint-plugins-dev.js"
+    },
     "./oxlint-plugin": {
       "module-sync": "./dist/oxlint-plugin.js",
       "node": "./dist/oxlint-plugin.js",
@@ -350,7 +359,7 @@
     }
   },
   "dependencies": {
-    "@oxc-project/types": "=0.148.0",
+    "@oxc-project/types": "=0.150.0",
     "@oxlint/plugins": "=1.79.0",
     "@vitest/browser": "4.1.11",
     "@vitest/browser-preview": "4.1.11",
@@ -361,23 +370,23 @@
     "@vitest/snapshot": "4.1.11",
     "@vitest/spy": "4.1.11",
     "@vitest/utils": "4.1.11",
-    "oxfmt": "=0.66.0",
-    "oxlint": "=1.81.0",
+    "oxfmt": "=0.68.0",
+    "oxlint": "=1.83.0",
     "oxlint-tsgolint": "=7.0.2001",
-    "vite": "npm:@voidzero-dev/vite-plus-core@0.3.1",
+    "vite": "npm:@voidzero-dev/vite-plus-core@0.3.3",
     "vitest": "4.1.11"
   },
   "devDependencies": {
-    "@emnapi/core": "2.0.0-alpha.4",
-    "@emnapi/runtime": "2.0.0-alpha.4",
-    "@napi-rs/cli": "^3.8.2",
+    "@emnapi/core": "2.0.0-alpha.5",
+    "@emnapi/runtime": "2.0.0-alpha.5",
+    "@napi-rs/cli": "^3.10.0",
     "@nkzw/safe-word-list": "^3.1.0",
     "@types/cross-spawn": "^6.0.6",
     "@types/semver": "^7.8.0",
     "@types/validate-npm-package-name": "^4.0.2",
     "@vitest/browser-playwright": "4.1.11",
     "@vitest/browser-webdriverio": "4.1.11",
-    "@voidzero-dev/vite-plus-prompts": "0.0.0",
+    "@voidzero-dev/vite-plus-prompts": "0.3.3",
     "bingo": "^0.9.3",
     "cac": "^7.0.0",
     "cross-spawn": "^7.0.5",
@@ -425,14 +434,14 @@
     "node": "^20.19.0 || ^22.18.0 || >=24.11.0"
   },
   "optionalDependencies": {
-    "@voidzero-dev/vite-plus-darwin-arm64": "0.3.1",
-    "@voidzero-dev/vite-plus-darwin-x64": "0.3.1",
-    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.3.1",
-    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.3.1",
-    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.3.1",
-    "@voidzero-dev/vite-plus-linux-x64-musl": "0.3.1",
-    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.3.1",
-    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.3.1"
+    "@voidzero-dev/vite-plus-darwin-arm64": "0.3.3",
+    "@voidzero-dev/vite-plus-darwin-x64": "0.3.3",
+    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.3.3",
+    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.3.3",
+    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.3.3",
+    "@voidzero-dev/vite-plus-linux-x64-musl": "0.3.3",
+    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.3.3",
+    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.3.3"
   },
   "scripts": {
     "build": "oxnode -C dev ./build.ts",

package/templates/generator/README.md

@@ -11,6 +11,20 @@ From monorepo root:
 vp create
 ```
 
+For automation, provide the directory and every required template option:
+
+```bash
+vp create <generator-name> --no-interactive -- --directory new-package --name new-package
+```
+
+Vite+ sets `VP_CREATE_INTERACTIVE=0` for non-interactive local Bingo generators.
+This starter then validates the arguments and runs Bingo's programmatic API.
+Missing options and existing directories fail before any files are generated.
+Existing generators are copied project files and are not updated by upgrading Vite+.
+To adopt this behavior, update their entrypoint to match this starter.
+Direct invocation uses the interactive CLI unless this variable is set to `0`.
+When adding template options, also add their CLI types in `bin/index.ts`.
+
 ## Development
 
 ```bash

package/templates/generator/bin/index.ts

@@ -1,10 +1,59 @@
 #!/usr/bin/env node
 
-import { runTemplateCLI, type Template } from 'bingo';
+import fs from 'node:fs';
+import { parseArgs } from 'node:util';
+
+import { runTemplate, runTemplateCLI, type Template } from 'bingo';
+import { z } from 'zod';
 
 import template from '../src/template.ts';
 
-// runTemplateCLI accepts the base `Template` type, which is wider than the
-// strongly typed template returned by createTemplate(). Cast through `unknown`
-// to bridge the two.
-process.exitCode = await runTemplateCLI(template as unknown as Template);
+async function main() {
+  if (
+    process.env.VP_CREATE_INTERACTIVE !== '0' ||
+    process.argv.includes('--help') ||
+    process.argv.includes('--version')
+  ) {
+    // runTemplateCLI accepts a wider type than createTemplate returns.
+    return await runTemplateCLI(template as unknown as Template);
+  }
+
+  // Add CLI entries here when adding options to src/template.ts.
+  const { values } = parseArgs({
+    options: {
+      directory: { type: 'string' },
+      name: { type: 'string' },
+      offline: { type: 'boolean' },
+      'skip-requests': { type: 'boolean' },
+      'skip-files': { type: 'boolean' },
+      'skip-scripts': { type: 'boolean' },
+    },
+  });
+  if (!values.directory?.trim()) {
+    throw new Error('Missing --directory. Pass generator options after -- in vp create.');
+  }
+  const options = z.object(template.options).parse(values);
+  if (fs.existsSync(values.directory)) {
+    throw new Error(`Directory already exists: ${values.directory}`);
+  }
+
+  await runTemplate(template, {
+    directory: values.directory,
+    mode: 'setup',
+    options,
+    offline: values.offline,
+    skips: {
+      requests: values['skip-requests'],
+      files: values['skip-files'],
+      scripts: values['skip-scripts'],
+    },
+  });
+  return 0;
+}
+
+try {
+  process.exitCode = await main();
+} catch (error) {
+  console.error(error instanceof Error ? error.message : String(error));
+  process.exitCode = 1;
+}