I really like this

I like this too, I think it'd be nice to allow something like

$ p create t3-app@latest --overrides ../path/to/my/tailwind.config.cjs --overrides ../path/to/tsconfig.json

and we'd infer the override based on the filename passed in 🤔

We can even have a config file in ~/.config/ct3a.toml or something and people would have to set that up just once pointing to their custom config files and then when using the CLI they won't have to pass any flags.

In addition to this we can have a flag like --no-overrides where you can get the default template without your custom files.

What do people prefer? Relative path or config file?

In addition to this we can have a flag like --no-overrides where you can get the default template without your custom files.

Yes opting out should be supported

What do people prefer? Relative path or config file?

I dont see why not support both. A parseOverrides function which would find stuff in a deterministic order and pass the parsed config to all the installers, so then you could even mix between a global config and per-project overrides.

Should also outline that we wouldn't take any responsibility whether your app will launch after applying all the overrides 🤣

Adding the discussion label as I think we should give this some thought before jumping into implementation

Should also outline that we wouldn't take any responsibility whether your app will launch after applying all the overrides

is it possible to check passed in files in order to check them if they are valid or not?

is it possible to check passed in files in order to check them if they are valid or not?

I don't think that's our responsibility since this would be an advanced usage feature, like you might have extra stuff in your override files that would require additional dependencies, for example the tailwind config might be using tailwind plugins that wouldn't be installed by default

Hey, still pretty new to the T3 ecosystem but I whipped up a simple implementation of this here #1091 :-)

Alright I've given this a little bit of thought. How does this sound?
Like @nexxeln suggested we have a toml file configured like so

[override]
override_dir = {path_to_dir_with_override_files}
overrides = [{path_to_file_or_dir}, {path_to_file_or_dir}]

[override.otherCustomConfig]
override_dir = {path_to_dir_with_override_files}
overrides = [{path_to_file_or_dir}, {path_to_file_or_dir}]

Where the base override table will be the default override configuration and subtables act as seperate configs you use with a
--useOverride [name_of_override_subtable] flag.
And like @juliusmarminge suggested we have a --override [path_to_dir_or_file_or_toml] where we can infer based on the file name / extension or directory name and parse them out accordingly.

Overrides and parsing work like this.

• Directory paths provided will be parsed by directory name and matched to default directories if names match. Directory paths provided that do not match to any default directory names will be treated as the root override directory. Same goes for file paths provided however if the file path does not match any default names then it will be added to whichever directory path it's contained in that matches or to the root if none match.
• The lower the level of provided path the higher the override priority. For example if
  ["C:\overrides", "C:\otherOverrides\src", "C:\overridesForServer\server", "C:\overridesForTrpcRouter\router"] were the provided overrides then any src folder within "C:\overrides" would be overridden by "C:\otherOverrides\src" and any server folder inside of there would be overridden by "C:\overridesForServer\server" and so on. File paths provided will take priority over all directory paths provided. --override flags will take higher priortity over toml files, any toml file provided by --override [path] will replace the base toml file and take lowest priority to other --override flags given. If any directory or file paths provided match eachother then the last one provided will take priority.
• File and directory paths will then be parsed based on package and the config will be provided to each installer.

This could add a lot of flexibility to scaffolding a project by adding the ability to create different configurations based on the needs of each project and mixing different configs with --override flags or paths added to overrides arrays inside of a toml.

@juliusmarminge @nexxeln I've created a draft and would like to hear your opinion and additional ideas for my proposal. I have implemented it in such a way that after a project is created, it checks if any of the following folders exist:

${T3_CONFIG}/override
${XDG_CONFIG_HOME}/t3stack/override
${HOME}/t3stack/override

If any of these folders exist, all files within the override directory are used to overwrite the defaults in the created project. This way, practically everything can be customized. I have also included some attachments in the draft #1503