Some questions about Starter kit equivalent

[Dtsiantaris]

In the docs it states:
..when you want to create what essentially is a “starter kit” that adds stuff on top of the official starter kit.
So i guess you create something like this AFTER you already used create-quasar(did i understand this in a wrong way?).
I was thinking if there was a way(maybe using app extensions) to have your own custom implementation of create-quasar and then after that also do all these amazing staff a AE provides(change the quasar.config etc).
For example i don't want the user to have an option about using Typescript or not. Also i want the user to only be able to have script setup with quasar/app-vite.
Where i'm getting at is, as per the docs have multiple projects sharing a common structure/logic, the scaffolding of the create-quasar is a huge part of that common structure. Could we manipulate it and force it?

[yusufkandemir]

If what you mean by not giving the option to choose TypeScript, enforcing script setup, etc. only about providing defaults for the existing create-quasar prompts, then see #5537.

If you completely want a different set of questions, structure, etc. then see https://quasar.dev/quasar-cli-vite/commands-list#scaffolding-from-a-custom-starter-kit, but it's a legacy option.

[Dtsiantaris]

TLDR!!
Thanks for the reply. I have read both. I am actually using this https://github.com/dreamonkey/cli-ghostwriter for providing options to the create quasar which I generate through custom prompts.
Essentially my question was, even though I understand why you guys don't have the cli prompts as part of the public API, maybe there was a better workaround that I'm not aware of.
For example in my implementation of my custom starter kit I tried adding support for the new app-vite2(awesome work btw) and somewhere down the line I broke the flow(maybe one prompt of the create-quasar changed slightly).
So basically testing any changes in the create-quasar as of now is a process of trial and error or reading the source code.
If you can think of something else let me know. Thanks a lot for your time! 👊🏻

[yusufkandemir]

somewhere down the line I broke the flow(maybe one prompt of the create-quasar changed slightly). So basically testing any changes in the create-quasar as of now is a process of trial and error or reading the source code.

If this is the main concern, then you can pin versions of create-quasar to avoid random breaks. This way, you can test new versions first and only then change the pinned version. For example, pnpm dlx create-quasar@1.8.2 would only use v1.8.2. Afterward, let's say 1.9.0 gets released, you can test it and if it still works fine for you, update it to pnpm dlx create-quasar@v1.9.0. This would be the best "workaround".

[Dtsiantaris]

Yes I thought about that and I think that you're right. This seems like the best workaround to not break things.
Thanks again!