Intercept `vp add oxlint` (and oxfmt, oxlint-tsgolint, vitest, vite?) and force the user to confirm the action

[connorshea]

Description

If the goal is to avoid users (and AI) trying to use these packages directly when they're using vp with a vite-plus project, it should probably trigger a warning for the user if they try to add/install the packages vite-plus is intended to consolidate.

Suggested solution

Add a confirmation step when a user runs vp install oxlint, vp add oxlint, vp add oxlint-tsgolint, etc, to inform the user/AI agent that vite-plus comes with these tools already, and thus adding the packages to the package.json is not useful.

Alternative

Letting users do this without any warning, potentially running into weird problems.

Additional context

No response

Validations

• Read the Contributing Guidelines.
• Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
• Check that there isn't already an issue requesting the same feature.

[naokihaba]

@fengmk2

I'm a bit concerned about the install-time warning approach.

If we only intercept vp add, we'll miss cases where someone manually edits their package.json. We wouldn't be able to detect the misconfiguration unless they use that specific command.

For a better DX, automatic detection and auto-fixing seem more reliable than a one-time warning. In #1456, we're already using the oxlint JS Plugin to fix IDE configs via vp check --fix. I think we can do the same here with a rule like vite-plus/no-bundled-deps to catch pre-bundled packages in dependencies. This way, we can report or fix the issue every time vp check runs.

I’m thinking of adding this to the work in #1456. Does that sound good to you?

[fengmk2]

@naokihaba It can serve as a default warning prompt. Some projects may need to depend on oxlint, such as projects implementing oxlint plugins.

Therefore, I think it's currently difficult to accurately determine with this intercept feature, so let's not consider it for now.