[feat] Support for custom recipes

[gurupras]

Describe the problem

I love how tauri supports so many recipes out-of-the-box. However, over time, I've built up a bunch of my own create-* packages that I would love to initialize my Tauri app with. Most of these extend existing templates (e.g. packages and configs on top of create-vite).

Describe the solution you'd like

Looking at the svelte merge, it looks like there's some custom, tauri-specific config that's required on top of the create-* package. Is it possible to extend existing recipes in some way?

Alternatives considered

Currently, I initialize a new tauri app and then go about installing packages and configs from my custom templates.

Additional context

No response

[nothingismagick]

That's a great idea. Maybe @jbolda would like to respond.

[amrbashir]

Honestly at first, I was opposed to the idea, because different front-end setups requires different integration with Tauri but the idea has grown on me and I think it can help reduce the amount of recipes we need to maintain at the core package.

I still don't know what is the optimal way to do this but I think it should be like this:

1. the custom template is hosted on github
2. • it has a cta-manifest.json that contains some metadata, like beforeBuildCommand, devPath...etc.
   • OR The github repo simply has a js file that exports a default object that follows the recipe interface. This approach will make the custom template have a finer control over how to bootstrap the template and if different package managers need different steps. I am skeptic about the security implications of this but it might be the best way imo because of the fore mentioned advantages and it would require less work on our end.

[gurupras]

I know you're trying to target a much broader audience and use-case, but for my uses, I don't even change Vite's ports or configs that much. I add some Vite plugins that I've come to love which can maybe be merged with Tauri's default config? It gets difficult because these are arrays rather than objects 😕

Beyond that, I'm just installing my own set of packages, setting up stylesheets, having my own eslint rules, etc.

[amrbashir]

I know you're trying to target a much broader audience and use-case, but for my uses, I don't even change Vite's ports or configs that much. I add some Vite plugins that I've come to love which can maybe be merged with Tauri's default config?

Not likely. We only bootstrap base projects. Plugins should be added by the user afterwards. Opinionated/Custom recipes shouldn't be baked in create-tauri-app. That's what you are asking for and I think the above proposal is the solution.

It gets difficult because these are arrays rather than objects 😕

Not sure what you mean by that.

Beyond that, I'm just installing my own set of packages, setting up stylesheets, having my own eslint rules, etc.

All should be done by you afterwards or a custom recipe using the above proposal.

[jbolda]

@gurupras do your custom templates have any Tauri "elements" in them? It sounds like you are looking to layer on the Tauri part of it atop your existing template. Is that correct?

[nothingismagick]

In light of the feedback from the 3.0 release's approach of removing several popular projects, we should address this now and find a way to tackle this from several approaches:

1. A public "community-owned" repo of recipes
2. A personal recipe (either local or remote)

[amrbashir]

So far, every discussion of this ended up at the same conclusion, what would create-tauri-app do different than just git clone <template-repo>? and the answer was nothing, it can't do anything more than just git clone which begs the question, is it worth it to implement?

Other direction was to curate the list of templates in awesome-tauri and provide them as a list in create-tauri-app but that was reject because of security concerns.

[escwxyz]

I am not sure if it's related but maybe it's worthy to check out how Astro handles integrations.