Description
As a developer using Vite+, I want a dedicated vp init command so that I can initialize a project in the current directory with a familiar, intuitive interface — similar to cargo init, npm init, or go mod init.
Currently, initializing a project in the current directory requires vp create [template] --directory ., which is functional but less discoverable. A dedicated vp init subcommand would improve the developer experience by matching established CLI conventions.
This is a follow-up to #1077 (vp create --directory . support) and #1097 (the PR that implemented it). Now that --directory . works correctly, the next step is to expose this as a first-class vp init command.
Suggested solution
- Add
vp init [template] as a new subcommand that internally delegates to vp create [template] --directory .
- No code duplication — reuse the existing create logic with
--directory . injected
- Without a template argument, show the interactive template selection prompt (same as
vp create)
- Block
vite:monorepo template and guide users to use vp create instead, since init is intended for single-project initialization in the current directory
- All existing
vp create flags (e.g., --no-interactive, --package-manager, --agent, --editor) should be forwarded as-is
Alternative
Keep only vp create --directory . without introducing a new command. This works but is less discoverable and doesn't match the conventions of other popular CLI tools.
Additional context
Validations
Description
As a developer using Vite+, I want a dedicated
vp initcommand so that I can initialize a project in the current directory with a familiar, intuitive interface — similar tocargo init,npm init, orgo mod init.Currently, initializing a project in the current directory requires
vp create [template] --directory ., which is functional but less discoverable. A dedicatedvp initsubcommand would improve the developer experience by matching established CLI conventions.This is a follow-up to #1077 (
vp create --directory .support) and #1097 (the PR that implemented it). Now that--directory .works correctly, the next step is to expose this as a first-classvp initcommand.Suggested solution
vp init [template]as a new subcommand that internally delegates tovp create [template] --directory .--directory .injectedvp create)vite:monorepotemplate and guide users to usevp createinstead, sinceinitis intended for single-project initialization in the current directoryvp createflags (e.g.,--no-interactive,--package-manager,--agent,--editor) should be forwarded as-isAlternative
Keep only
vp create --directory .without introducing a new command. This works but is less discoverable and doesn't match the conventions of other popular CLI tools.Additional context
vp create --directory .support was added in feat(create): support creating project in current directory #1097, which auto-derives the package name from the current directory namevp initentry point; it does not change any existingvp createbehaviorValidations