I was leaning toward an option that would not be mutually exclusive of the others (and I think the linked issues were also asking for this). I would like to see a--minimal option that just does not generate the HelloWorld/WelcomeItem/TheWelcome/Icon* components but lets developers pick TS, vitest, etc.

Or maybe even change the default behavior to generate a lighter version.

I think I can expand it to work with other options with some effort.

But what should we do whenpinia androuter is selected alongsideminimal/bare? Do people really need arouter template without any boilerplate code?

I think the complaint is mostly that the default setup is too verbose and the first thing you have to do after creating a new project is to delete all the components, all the CSS and assets etc.

Angular CLI for example only generates theApp component, with an empty route config if the router is selected.
The Angular logo is inlined as SGV in the template which makes it easier to get rid of (even if the component's template is still way too verbose in my opinion).

That's why I would even consider simplifying the default instead of adding another option.
But I think adding another option without supporting the existing ones won't really answer what the community is asking in these issues IMHO.

Refactored!

That's why I would even consider simplifying the default instead of adding another option.

IMO we still need some kind of example code for new users, so the default is a bit more verbose than the ones increate-vite. In fact, I had even included a composable example in the original implementation, only to be removed after the feedback from Evan…#2

I'm open to the idea of making the templates "easier to delete", but I need help on that.

That's why I would even consider simplifying the default instead of adding another option.

I absolutely love and agree with the "easier to delete" approach, as mentioned in Evan's feedback.

In my opinion, adding one more prompt to ask about the bare configuration, with a sensible default choice, would be easier for new users who might not notice this feature in the docs. Additionally, we can provide a--bare argument forcreate-vue to skip the prompt and directly initialize with the "bare" option (set toYes ortrue).

As an Angular user, I appreciate how the Angular CLI simplifies things with just prompts for the project name and stylesheet format, followed by generating a bare project. However, without some example components, it can be challenging for newcomers to understand the structure or workflow without reading the docs.

For my suggestion, I propose adding awelcome folder with easily removable example components. This would allow new users to follow our examples while keeping the project clean and straightforward for experienced developers. Alternatively, we could add a prompt, with an argument to skip it, to ensure users understand what they are configuring, enhancing the overall developer experience.

For my suggestion, I propose adding awelcome folder with easily removable example components.

I just tried this locally, and I found it made little difference compared to the current approach…
It's essentially moving the currentsrc/components folder tosrc/welcome.

I also tried moving markups inApp.vue into a standalone component insidesrc/components and leaving only one line ofimport and a single<TheWelcome> tag inApp.vue. This did remove some visual clutter, but IMHO it's an inferior approach - we traded the opportunity to showcase essential Vue.js features for next-to-nothing, and the users still don't like it. Because according to the feedbacks in the linked issues, they want a plain<p> tag inApp.vue, not even imports.

Anyway, even with all those experiments, I find the essential workflow in this PR still works, so I believe we can move forward with this implementation.

Now we need to decidewhether to add a user-facing prompt for this feature.
I like the word choice in#637 so I'm now inclined to add it here.

I have no stronger opinion about a user-facing prompt. If we go with it, I would use something other than "instructions", as it feels like you'll get a tutorial.

I haven't tested the PR, but I think we should add the--bare flag to the CI with a few examples (just bare, with TS, with tests, etc).

For my suggestion, I propose adding a welcome folder with easily removable example components.

@haoqunjiang In my opinion, I would move thewelcome/ folder tosrc/components, making itsrc/components/welcome/. TheApp.vue file would remain insrc/ or its default position. This approach minimizes changes to the existing structure, keeping it familiar for beginners. It aligns with thecomponents pattern, reducing potential confusion while maintaining consistency with the current folder structure.

I have no stronger opinion about a user-facing prompt. If we go with it, I would use something other than "instructions," as it feels like you'll get a tutorial.
I haven't tested the PR, but I think we should add the--bare flag to the CI with a few examples (just bare, with TS, with tests, etc).

@cexbrayat I agree with using something other than "instructions" or adding more options in the tutorial.
Adding the--bare flag to the CI is a great idea, especially for experienced users who want to create a project without examples. We should also include documentation about the--bare flag in the README or docs so users can easily find and understand this option.

For now, I believe adding the--bare flag tocreate-vue is an excellent choice. It introduces a new configuration option without affecting the current user experience.

I haven't tested the PR, but I think we should add the--bare flag to the CI with a few examples (just bare, with TS, with tests, etc).

😂 I have to open another PR to refactor the CI first, because the job matrix would become way too complex after adding yet another flag…
#640

I just noticed the Vue template onStackBlitz. It includes onlyApp.vue andHelloWorld.vue inside thecomponents/ folder, along with a single stylesheet file,style.css. This setup makes it very easy to remove example components and unnecessary configurations.

As a Vue user, I personally don’t see a need for bothstyle.css andmain.css initially. I haven’t encountered this issue, possibly because I almost always use Tailwind CSS or UnoCSS.

If we decide to go further with restructuring the folders and merging some files—similar to theStackBlitz approach—it could make starting a project simpler and help users follow consistent patterns.

These are just my ideas.

StackBlitz pulls fromcreate-vite templates. Vite starter templates wereintentionally minimal. So they serve a different purpose thancreate-vue templates.
I agree that could be used as an inspiration for us to simplify the templates.

As a Vue user, I personally don’t see a need for bothstyle.css andmain.css initially. I haven’t encountered this issue, possibly because I almost always use Tailwind CSS or UnoCSS.

We don't usestyle.css, butbase.css along withmain.css.
It's a common pattern among medium-to-large size projects. One is for CSS resets and common variables with minimum business logic and might be shared across projects, the other imports the base and includes actual global styles for the app.

If you are using Tailwind, you might have encountered it too, just in different forms: the@tailwind base directive is similar toimport 'base.css' in plain CSS.
In the VitePress theme forhttps://vuejs.org, there're also bothbase.css andindex.css.
In Bootstrap, the names are a bit different; they usereboot.scss andbootstrap.scss.

We don't usestyle.css, butbase.css along withmain.css.

I’m sorry for mistakenly recalling the wrong file name.

It's a common pattern among medium-to-large size projects. One is for CSS resets and common variables with minimum business logic and might be shared across projects, the other imports the base and includes actual global styles for the app.

That’s a good approach for developing projects. I’ve sometimes mixed them into a single file, but I realize now that separating reset CSS into one file and global styles into another is a good practice.

@haoqunjiang Thank you for teaching me how to better manage styles in projects. 😁

Let's merge this PR now. Thanks for all the reviews!
I plan to ship another release just before the holidays, with one more PR to add documentations and a--help CLI option.

Regarding the remaining undecided matters like the--bare prompt and simplifying default templates, let's carry on the discussions in dedicated issues/PRs later.