feat(cli): enforce vite-plus import lint rule

[Han5991]

Summary

• add a bundled Oxlint JS plugin rule that rewrites vite/vitest imports to vite-plus
• enable the rule by default in generated and migrated lint config
• cover the new wiring with unit tests and snapshot tests

Testing

• pnpm exec tsc --noEmit --pretty false
• pnpm exec tsc --ignoreConfig --noEmit --pretty false --module esnext --moduleResolution bundler --target es2022 --skipLibCheck packages/cli/snap-tests/lint-vite-plus-imports/vite.config.ts
• local snap tests for command-init-inline-config and lint-vite-plus-imports

Closes #1301

[netlify]

✅ Deploy Preview for viteplus-preview ready!

Name	Link
🔨 Latest commit	7930f65
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-preview/deploys/69e77fa0343ca800086b43ad
😎 Deploy Preview	https://deploy-preview-1408--viteplus-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[fengmk2]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7eceea6afe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

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".

[fengmk2]

Awesome, the import rewrite logic can be completely replaced with the oxlint plugin.

[Han5991]

Awesome, the import rewrite logic can be completely replaced with the oxlint plugin.

Makes sense. I focused this PR on the unsafe rewrite fix first, and I can move the remaining import rewrite logic into the oxlint plugin in a follow-up.

[camc314]

it would be ideal to use createOnce over create due to its perf advantages

[fengmk2]

BTW: @camc314 We need an oxlint plugin rule to guide us on how to write good oxlint plugins 😃

[camc314]

This looks good! but we should definitely use oxlint's types rather than handrolling it, it duplicates code, and might cause issues in future!

[Han5991]

@fengmk2

The failure appears to come from a version skew in the global snap test.

In this test, vp create and vp check are executed by the locally built Vite+ CLI under test. However, after vp install, the generated application installs vite-plus@latest from the npm registry into its own node_modules.

The local CLI generates a lint config that references vite-plus/oxlint-plugin. When oxlint loads that config, it resolves vite-plus/oxlint-plugin from the generated application's node_modules, not from the local CLI package.

That means oxlint sees the registry-installed vite-plus@latest. That published package does not currently expose the new ./oxlint-plugin subpath, so resolution fails.

This also explains why the other vite-plus/* imports appear to work: those subpaths already exist in the published package, while vite-plus/oxlint-plugin only exists in the local build being tested.

[Han5991]

I think there are three possible ways to address this.

1. Install the local Vite+ artifact in the generated app

The failure is caused by mixing the locally built CLI under test with vite-plus@latest from the registry. We could make the generated app install the same local Vite+ artifact set as the CLI under test, for example via a packed local tarball.

This avoids the version skew and keeps the test focused on the current build. A packed tarball seems better than link: because it is closer to a real package install and still verifies the published package shape, including package.json#exports.

2. Resolve the built-in oxlint plugin from the CLI package

Another option is to make vp check resolve Vite+’s built-in oxlint plugin from the CLI package itself before passing the lint config to oxlint.

That would keep the generated app’s registry-installed dependencies intact, but it changes production resolution behavior. I would be careful with this because it may be harder to justify unless built-in Vite+ plugins are explicitly meant to be provided by the running CLI rather than by the project’s installed vite-plus.

3. Treat this as a registry/local version skew exposed by the snap

We could also leave the test behavior as-is and consider the failure expected until the package containing ./oxlint-plugin is published.

This is the most conservative option, but it means the global snap test can fail whenever the local CLI starts generating config that depends on an unreleased vite-plus subpath.