When we do npx frontity create my-frontity-project or npx frontity create-package my-frontity-package being able of select some some automatic configurations being done for your project.
We already can add Typescript but some more interesting options could be:
Hey, great one @juanma.
Would this be better tracked with individual features for the individual configurations?
I know we had a list somewhere:
And maybe we could do another feature to search and add official Frontity packages:
Sorry guys, I postponed it and I didn’t get notified until today. I would like to understand it a bit better because I’m not getting it. Correct me if I’m wrong but I feel that we would need three different things:
Right now, users can add support for TypeScript just by adding --typescript while doing npx frontity dev. It’d be nice to have something similar for other configurations:
If this is the case, I think it’s better to divide them. If I am not wrong, it makes sense to do them separately right? This way, we can prioritize just one of them if needed, and even other users could join and develop the rest of them (or new ones we didn’t think about).
After doing npx frontity create we could show the list of these possible configurations, let users select which ones they want to apply, and run --typescript ourselves for example.
Example
TypeScript PrettierThiw way, we would just run --typescript and --prettier.
After doing npx frontity create we could show the list of the official frontity packages and let the users decide which ones they want to install automatically.
Example
Gutenberg Google AnalyticsThis way, we would install Gutenberg and Google Analytics packages.
Could you explain to me if this is the case and, if not, why not please?
If this is the case I feel we’d need:
Hi! I’m interested on working on improvements for Frontity CLI.
I’ve been reading the feature discussions and it looks a bit chaotic right now. This feature though seems like the one that could wrap the others.
I’m personally interested on working on:
frontity create (Full TypeScript support in `frontity create`)frontity create (I didn’t find feature discussion)I was thinking of a system where we could choose the packages, as mentioned by @SantosGuillamot , and being prompted about settings for those packages if needed (like @frontity/wp-source) when running frontity create and maybe a --confirm option that would just select the defaults for everything.
Let me know what can I do towards start working on these topics, which would be the first steps.
Hi @orballo! Glad to hear you are interested on working on this 
We haven’t been focused on this yet and we still have to do a deep research about the whole workflow in the CLI, that’s why there is a lot of information missing.
Our initial idea is to create a workflow where Frontity users can easily select their configurations just by answering questions on the CLI. A possible workflow could be:
@frontity/mars-theme (default)@frontity/twentytwenty-themeHere we could have a list with the official Frontity packages to easily let the users decide which ones they want. It could have some of them selected by default (like wp-source for example), but users should be able to easily deselect them. It seems this should be possible with our current CLI tool - https://github.com/SBoudrias/Inquirer.js#checkbox---type-checkbox. The list could be something like this:
Example
WordPress Source (recommended) Tiny Router (recommended) Google AnalyticsIn the future we could ask more specific questions.
Here, as with the packages, we could have some of them selected by default.
TypeScript PrettierRegarding your questions, and how to start working on these topics, I assume the best option is to work on them one by one, and discuss about them independently in each Feature Discussion. I guess it’s not necessary to do all of them together at once.
I feel the first step for most of them would be to be able to select each option directly from the create command like we are doing with --typescript, so we could start from there.
Going to the points you mention:
npx frontity create my-project )Maybe we could start by adding that possibility to the theme option in the create command. This way, if you want to start a Frontity project with and empty theme you could do:
npx frontity create --theme empty-theme
We could name it empty-theme or any other way. In the future, I guess that the CLI could use that.
We can talk in the Feature Discussion about what needs to happen if someone run that command.
frontity create (Full TypeScript support in frontity create)Regarding this, I totally agree that we should provide Full TS support in frontity create. I think you know better than me which things are lacking, so feel free to list them on the Feature Discussion and we could start from there.
Moreover, it would be also great to have a starter TS theme (like mars or even simpler), but it’s something we don’t have right now neither.
frontity create (I didn’t find feature discussion)This is also something we had in mind and it would be really nice to have. Again, I think the first step would be to allow something like:
npx frontity create my-project --git
I don’t fully understand all the things that would be needed in terms of code, so if you are interested feel free to create a Feature Discussion and we can start defining them there.
As mentioned above, it would be really nice to add a new question in the CLI where users can easily do this. Again, if you are planning to work on it, feel free to open a Feature Discussion to discuss about it. If not, I will try to split all of them after Christmas
Good news!! 
My two cents:
We already have that! It is called --no-prompt.
Instead of hardcoding something, I would simply create a real theme, but empty. For example @frontity/empty-theme.
That way it is going to be much easier to integrate and maintain. The only thing we need to do is to add the “Empty theme” option in the theme input that points to @frontity/empty-theme.
I migrated mars-theme to TypeScript for the WooCommerce proof-of-concept: https://github.com/frontity/woocommerce-proof-of-concept/tree/dev/packages/woocommerce-theme/src/components
I think it’s not perfect yet, but it could be a great start for a mars-theme-ts package
I agree with @SantosGuillamot that the best way to go would be to add the functionality first with CLI args, like --git, and then create the interface to select/unselect options.
@orballo what do you think?
Yes, I agree. I was thinking about starting with the support for TypeScript. I’ll post in the proper thread before I start working on it.
I’ve been working on a starter theme and one of the things I think would be nice is a way to provide a custom frontity.settings.js file to be used as a starting point. My starter theme will have some package dependencies and it would be great to have a way within the frontity cli to bootstrap the project with the packages installed and added to the frontity.settings.js file.
I wonder if we could have either an option (or the default behavior) in the create command that would use a frontity.settings.js file directly from the theme repo?
- my-frontity-starter-theme
-- src/
--- index.ts # the theme settings file
-- type.ts
-- frontity.settings.ts # the project settings template, only used by frontity create commandUhm, you mean defining the state that should be populated in the frontity.settings.js file for that package, right?
// /package/my-package/frontity.settings.js
export default {
state: {
theme: {
colors: {
primary: "white",
secondary: "blue",
},
},
},
};
Ends up being:
// /frontity.settings.js
export default {
packages: [
{
name: "my-package",
state: {
theme: {
colors: {
primary: "white",
secondary: "blue",
},
},
},
},
],
};
Yeah, that makes sense
Do you want to open a new FD for that?
It could also be used once we introduce an npx frontity install-package command, which could ask you:
/packages) or not (/node_modules).frontity.settings.js file).I’m working on frontity create support for TypeScript, next I want to initialise git, and then I want to implement something that allows to generate an empty project. And by empty I mean that no local package is installed and only frontity and @frontity/core are dependencies in the root.
For this I was thinking about a flag like --empty that removes the theme and all its dependencies.
Let me know what you think.
Hi again!
I just opened this PR draft regarding the --git option. I think we need to decide what is included in .gitignore and what are the git commands run when initializing. I coded a quick implementation, but it might need more thinking.
I understand your point here because I guess you want to use your own theme, source and router packages right? If I’m not mistaken, in a Frontity project, users will need at least a theme, a source and a router as dependencies, so I’m not sure if having an option to not include any of them as dependencies could be confusing.
Thanks a lot for opening it I think we can keep the conversation in the Pull Request.
I don’t think this is true. There are scenarios where the user might want to build he’s own theme, use another source and router packages that are not currently included, or just build a small package that doesn’t need a theme. If an option like --empty is present, it doesn’t mean it needs to go into the menu. I think that having an option that only gives me frontity and @frontity/core should exist because that is what Frontity actually is. The packages, either needed or not (needed mostly if you think about WP), are additions.
Yeah, as long as it is opt-in, an --empty or --blank option is perfectly fine
The --git option PR is ready for review.
If you agree on the --empty option I can work on that next. I don’t know what would be better, if --empty or --blank. Because at some point there might be an empty-theme and be confusing.
OKay, let’s do that then . Both --empty and --blank are good for me.