skip package-manager operations when a requested option is unsupported

[jong-kyung]

Summary

Could we standardize how Vite+ handles unsupported package-manager options?

When the selected package manager cannot honor an option, I propose showing a clear diagnostic and skipping the entire requested operation rather than removing the option and continuing.

Current behavior

Unsupported options currently produce different outcomes.

Request	Selected PM	Current behavior
vp update --no-save	Yarn	Warns, drops the option, and runs the update
vp update --filter <workspace>	Bun <1.4	Warns, drops the filter, and runs the update
vp update --filter <workspace>	Yarn Berry	Returns an error without executing
vp pm audit --fix	Yarn	Warns and returns Noop

The shared not_supported(...) handling records a warning, resets the option to its default value, and continues into command resolution. It does not prevent execution.

Some individual resolvers also omit options without a diagnostic. Those cases need to be checked against the native PM's behavior before classifying them as unsupported.

Why change this?

Removing an option can change the operation the user requested:

• Dropping --no-save allows manifest changes.
• Dropping --filter removes the requested workspace restriction.

Printing a warning does not preserve those constraints.

Proposed policy

For Vite+-owned named options on normal project package-manager commands:

• Preserve supported options, including translations to native equivalents.
• If the selected PM or version cannot honor an option, report the limitation and skip the entire operation.
• Apply this behavior to not_supported(...) instead of dropping the option and continuing.
• Keep errors for malformed input and invalid argument combinations.

Example diagnostic:

yarn does not support --no-save for update. No update was performed.

Scope

• Exclude Vite+-managed global package operations, which use Vite+'s own management logic rather than the selected project's PM.
• Leave raw pass-through arguments after -- unchanged in this proposal.
• Leave existing command translations and fallback policies unchanged.

[jong-kyung]

@fengmk2 I think we should skip the entire operation when a requested option is unsupported, rather than drop the option and continue. What do you think about this direction? We should also decide whether to exit successfully after a warning or return a non-zero status so scripts and CI can detect that the operation was skipped.

[fengmk2]

@jong-kyung throw error and stop execute sound good to me.

[jong-kyung]

@jong-kyung throw error and stop execute sound good to me.

I will prepare a PR 🫡