Skip to content

[Feature]: winapp init should be a little smarter when figuring out what project to focus on #476

@Jaylyn-Barbee

Description

@Jaylyn-Barbee

Is your feature request related to a problem? Please describe.

When I init in a general folder where the project doesn't live init just creates the files no matter what.

Describe the solution you'd like

init should be smarter about finding well known project types like csproj or sln before deciding to place files.

Proposed Spec

Possible flow:

  1. On init run, winapp CLI will detect if a compatible framework lives in the passed directory. For each of our supported frameworks we can check via:
  • Tauri: tauri.conf.json at one level below the root
  • Rust: Cargo.toml at the root
  • Electron: Parsing package.json for electron dependency
  • CPP: CMakeLists.txt at root
  • Flutter: pubspec.yaml at project root
  • Dotnet: .csproj at project root

Kick all these off in parallel and return on the first positive result?

Questions: for this step:

  • Do we want to detect specific Dotnet project types for enhanced output on the next step?
  • We don't support other C++ build systems besides CMake or do we?
  1. If a project type is detected, we can improve the initial init output with something like: `Tauri application detected. Starting init process..."

Questions for this step:

  • While we are it, I know we talked about some of the init prompts not being relevant to certain projects, should we take this as a chance to adjust what we show users?
  1. If no project is detected, we have two options:
  • Fail quickly with an informative error: We did not detect a compatible development framework in the input directory.
  • Allow to init anyway via a prompt with a verbose message explaining that most things won't work. Would they have a reason to do this?

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions