🛠 Tooling: Prevent Templates from defining --repository or --owner to values that can't be stringified into a repository locator

[JoshuaKGoldberg]

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

A few places in code define owner and repository as options that must exist:

create/packages/create/src/options.ts

Lines 15 to 25 in 78bc44b

	export type MinimumOptionsShape = AnyOptionalShape & RequiredOptionsShape;
	export interface RequiredOptions {
	owner: string;
	repository: string;
	}
	export interface RequiredOptionsShape {
	owner: z.ZodOptional<z.ZodString>;
	repository: z.ZodOptional<z.ZodString>;
	}

That's not enforced. Repositories can override those options, sort of, maybe. It's not clear what happens. Which is not great: we wouldn't want them to, say, override owner to a z.number().

I'd like to:

• Have the tooling throw an error if a template tries to define either as an option
• Pipe MinimumOptionsShape through places that might find it useful
• Document this in https://www.create.bingo/cli#flags
• Document this in the templating engine docs, in some way

Additional Info

It would be nice to represent this in TypeScript types, but I couldn't figure out a nice way with the type parameter constraints...

💝

[boneskull]

Hi, I'm Bob Dobbs at Amalgamated Feed & Hay. I want to provide a template for my team to use, but all packages we make should be owned by amalgamated_feed_and_hay, so I want to provide z.literal('amalgamated_feed_and_hay') instead. Please don't harsh my mellow

[JoshuaKGoldberg]

Haha great point. How about: they can be defined and overridden, but it must be some kind of string?

[boneskull]

a string might be too strict

I guess my overall point is to freely allow all manner of nonsense input unless you are really, really sure it will fundamentally break functionality