Minor improvement to whichapi & anthropic configuration

[DaveHogan]

I made a typo when configuring my whichApi value🙄

Hopefully, this PR prevents others doing the same by forcing the values to be selectable from an enum.

Whilst in here, I made the max_tokens and model values for anthropic a configurable value.

I'm happy to implement similar approach on the others configs and refactor the configuration a little but I didn't want to jump in without running by the void owners. I would also suggest waiting until PR #22 is implemented as that introduces some new configuration values for Ollama integration and don't want to raise a bunch of conflicts

[okxiaoliang4]

relate:

when #41 merged i will improve the configuration in this pr okxiaoliang4#1

[andrewpareles]

We shouldn't have ?? 'anthropic' or ?? 1024. These are already defaults in package.json; it doesn't make sense to hard-code them in twice.

Please make these all default the empty string, and parse values where they're used.

[DaveHogan]

Yeah that's fair, but if I was to parse the values like below should we have a fallback or alert the user in some manner?

const parseWhichApi = (value: any): string => {
	if (typeof value === 'string' && ['anthropic', 'openai', 'greptile', 'ollama'].includes(value)) {
		return value;
	}
	// What to do in the negative cases here?
	return 'anthropic'; 
}

Also maxTokens is a number, would you suggest converting that to string or keeping as a number with 0 as a default

parseMaxTokens(config.get('anthropicMaxToken')) ?? 0

[andrewpareles]

To keep everything consistent, I suggest making everything a string. Let’s parseInt() when we need an int.

I think we should just raise an error in the “negative” case. This makes it much clearer what’s going on in the case of an unexpected value. Also, I’m pretty sure the negative case of whichApi can never be reached anyway - package.json says the value is an enum.

[DaveHogan]

I've rejigged this from your suggestions @andrewpareles