vite-plus 0.3.1 → 0.3.2

package/docs/guide/lint.md

@@ -18,7 +18,9 @@ vp lint --type-aware
 
 ## Configuration
 
-Put lint configuration directly in the `lint` block in `vite.config.ts` so all your configuration stays in one place. We do not recommend using `oxlint.config.ts` or `.oxlintrc.json` with Vite+.
+Put lint configuration directly in the `lint` block in the root `vite.config.ts` so all your configuration stays in one place. We do not recommend using `oxlint.config.ts` or `.oxlintrc.json` with Vite+.
+
+Vite+ does not currently support nested lint configuration. For now, use [`lint.overrides`](/guide/monorepo#root-config-with-overrides) in the root `vite.config.ts` for file- or package-specific rules. The long-term behavior is open for discussion; [share your use case and expectations](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) to help shape it.
 
 For the upstream rule set, options, and compatibility details, see the [Oxlint docs](https://oxc.rs/docs/guide/usage/linter.html).
 
@@ -50,3 +52,58 @@ This path is powered by [tsgolint](https://github.com/oxc-project/tsgolint) on t
 If you are migrating from ESLint and still depend on a few critical JavaScript-based ESLint plugins, Oxlint has [JS plugin support](https://oxc.rs/docs/guide/usage/linter/js-plugins) that can help you keep those plugins running while you complete the migration.
 
 JS Plugins also enable [writing your own custom rules](https://oxc.rs/docs/guide/usage/linter/writing-js-plugins.html) for Oxlint.
+
+### Writing Your Own Rules
+
+Import the plugin authoring API from `vite-plus/lint/plugins`:
+
+```js [lint/my-plugin.js]
+import { definePlugin, defineRule } from 'vite-plus/lint/plugins';
+
+const noFoo = defineRule({
+  meta: { messages: { noFoo: 'Do not name things "foo".' } },
+  create(context) {
+    return {
+      Identifier(node) {
+        if (node.name === 'foo') {
+          context.report({ node, messageId: 'noFoo' });
+        }
+      },
+    };
+  },
+});
+
+export default definePlugin({
+  meta: { name: 'my' },
+  rules: { 'no-foo': noFoo },
+});
+```
+
+Register it under `lint.jsPlugins` and enable its rules:
+
+```ts [vite.config.ts]
+import { defineConfig } from 'vite-plus';
+
+export default defineConfig({
+  lint: {
+    jsPlugins: ['./lint/my-plugin.js'],
+    rules: {
+      'my/no-foo': 'error',
+    },
+  },
+});
+```
+
+For rule tests, `RuleTester` is available from `vite-plus/lint/plugins-dev`.
+
+Both entrypoints re-export the copy that ships with Vite+. The API therefore
+always matches the bundled Oxlint.
+
+Use them instead of adding `@oxlint/plugins` or `oxlint` as a direct
+dependency. A separately pinned copy can drift from the linter that loads your
+plugin. It also does not resolve from a plugin file under pnpm's strict layout,
+unless every package that holds a plugin declares it.
+
+`vp migrate` rewrites existing `oxlint` and `@oxlint/plugins` imports for you.
+See [Oxlint JS Plugin Imports](/guide/migrate-rules#oxlint-js-plugin-imports).
+The `vite-plus/prefer-vite-plus-imports` rule reports any that come back.

package/docs/guide/migrate-rules.md

@@ -250,6 +250,44 @@ surface are written against `vite-plus` by hand.
   needed.
 - Existing `vite-plus/test*` imports are left unchanged.
 
+### Oxlint JS Plugin Imports
+
+Vite+ bundles Oxlint, so the migration removes a standalone `oxlint`
+dependency. Your own Oxlint JS plugins import the authoring API by name. That
+import stops resolving when the dependency goes away. `vp lint` then fails to
+load the plugin.
+
+The migration repoints those imports at Vite+:
+
+- It rewrites `@oxlint/plugins` to `vite-plus/lint/plugins`.
+- It rewrites `oxlint/plugins-dev` to `vite-plus/lint/plugins-dev`.
+- It rewrites `oxlint` to `vite-plus/lint/plugins` when the import names a
+  binding from the authoring API, such as `defineRule`, `definePlugin`, or
+  `Context`. Older Oxlint releases exposed that API from the main entry. It now
+  lives in `@oxlint/plugins`.
+
+An import through Vite+ always matches the version of Oxlint that Vite+
+bundles. You pin no second package. The import also resolves from any package
+that already depends on `vite-plus`.
+
+The migration leaves three forms alone:
+
+- `oxlint` imports that name only the config surface, such as `defineConfig`,
+  `OxlintConfig`, or `OxlintOverride`. These still resolve against the
+  standalone package.
+- Default and namespace `oxlint` imports. They name no binding, so the
+  migration cannot tell the two surfaces apart.
+- Bare side-effect `oxlint` imports, for the same reason.
+
+The migration also skips a package that declares `oxlint` or `@oxlint/plugins`
+in `dependencies` or `peerDependencies`, or `@oxlint/plugins` in
+`optionalDependencies`. These dependencies can supply a published Oxlint plugin.
+Its consumers may not run Vite+.
+
+The cleanup retains a development dependency on `@oxlint/plugins` when source,
+package import aliases, or built plugins still reference it. This includes
+ignored output in directories such as `dist`, `build`, and `out`.
+
 ### What Is Never Rewritten
 
 - `declare module 'vitest'` and `declare module '@vitest/browser*'`: module

package/docs/guide/migrate.md

@@ -117,7 +117,7 @@ After the migration:
 
 - Confirm `vite` imports were rewritten to `vite-plus` where needed
 - Confirm `vitest` imports were rewritten to `vite-plus/test` (and `@vitest/browser*` to `vite-plus/test/browser*`) where needed
-- Remove old `vite`, `vitest`, and `@vitest/browser*` dependencies only after those rewrites are confirmed — `vite-plus` ships them as direct deps
+- On pnpm, keep the `vite`, `vitest` dependency entries configured by `vp migrate` so the workspace aliases and overrides stay effective; with other package managers, you can remove them once those rewrites are confirmed
 - Move remaining tool-specific config into the appropriate blocks in `vite.config.ts`
 
 Command mapping to keep in mind:

package/docs/guide/monorepo.md

@@ -6,6 +6,8 @@ Because `vite.config.ts` is just JavaScript, you can choose to put your entire c
 
 ## Root Config With Overrides
 
+Vite+ does not currently support nested lint or format configuration. Package-level `lint` and `fmt` blocks are not automatically applied. For now, define file- or package-specific settings with overrides in the root `vite.config.ts`. The long-term behavior is open for discussion; [share your use case and expectations](/guide/troubleshooting#nested-lint-or-format-config-is-not-applied) to help shape it.
+
 Use `lint.overrides` for Oxlint rules that only apply to some packages:
 
 ```ts [vite.config.ts]

package/docs/guide/troubleshooting.md

@@ -28,6 +28,20 @@ The Oxlint type checker path powered by `tsgolint` does not support `baseUrl`.
 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`
 
 If VS Code has multiple folders open, the shared Oxc language server may pick a different workspace than expected. That can make it look like `vite.config.ts` support is missing.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vite-plus",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "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.149.0",
     "@oxlint/plugins": "=1.79.0",
     "@vitest/browser": "4.1.11",
     "@vitest/browser-preview": "4.1.11",
@@ -361,16 +370,16 @@
     "@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.67.0",
+    "oxlint": "=1.82.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.2",
     "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",
+    "@napi-rs/cli": "^3.9.0",
     "@nkzw/safe-word-list": "^3.1.0",
     "@types/cross-spawn": "^6.0.6",
     "@types/semver": "^7.8.0",
@@ -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.2",
+    "@voidzero-dev/vite-plus-darwin-x64": "0.3.2",
+    "@voidzero-dev/vite-plus-linux-arm64-gnu": "0.3.2",
+    "@voidzero-dev/vite-plus-linux-arm64-musl": "0.3.2",
+    "@voidzero-dev/vite-plus-linux-x64-gnu": "0.3.2",
+    "@voidzero-dev/vite-plus-linux-x64-musl": "0.3.2",
+    "@voidzero-dev/vite-plus-win32-x64-msvc": "0.3.2",
+    "@voidzero-dev/vite-plus-win32-arm64-msvc": "0.3.2"
   },
   "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;
+}