How to handle the incompatible types in address.zipCodeByState()

[ST-DDT]

faker/src/address.ts

Lines 126 to 133 in f520968

	zipCodeByState(state: string): string | number {
	const zipRange = this.faker.definitions.address.postcode_by_state[state];
	if (zipRange) {
	// TODO ST-DDT 2022-02-10: Fix types
	return this.faker.datatype.number(zipRange);
	}
	return this.faker.address.zipCode();
	}

faker/src/definitions/address.ts

Lines 7 to 13 in f520968

	/**
	* Postcodes patterns by state
	*/
	// TODO ST-DDT 2022-01-31: address.zipCodeByState() expects only { [state: string]: { min: number; max: number } }
	postcode_by_state:
	| string[]
	| { [state: string]: { min: number; max: number } };

The following languages specify a string[] (4):

• ar
• en
• he
• ur

The following locales specify Parameters<Datatype['number']> (1):

• en_US

AFAICT there is no way to access the string[] values using a string key and if there was a way the result would be incompatible with the datatype.number() function.

I checked the string[] postcode_by_state locale files and it is exactly like their postcode locale file, so even if we remove them, the fallback to the normal zipCode method would work and return the same values.

We have two choices:

• Add support for string[] values
• Remove the string[] from the type and the corresponding files

Created from #541

[ST-DDT]

I'm in favor or removing string[] and the offending files.

[xDivisionByZerox]

After some investigation, I come to the same conclusion. A string[] doesn't make sense for the use case IMO.

[import-brain]

I'm also in favor of removing string[].