Typescript: randEmail, randFirstName, and randLastName (and likely more) return type string[] when no options present

[kpervin]

Is this a regression?

No

Description

Expected Behavior:

The following

const fields = {
    contactEmail: randEmail(),
    contactFirstName: randFirstName(),
    contactLastName: randLastName(),
  };

should report return values of

const fields = {
    contactEmail: string,
    contactFirstName: string,
    contactLastName: string
  };

Current behavior:

The above functions result in reporting

const fields = {
    contactEmail: string[],
    contactFirstName: string[],
    contactLastName: string[]
  };

Suggested fix:

declare function rand*<Options extends FakeOptions = undefined>(options?: Options): Options["length"] extends number ? string[] : string;

instead of

declare function rand*<Options extends FakeOptions>(options?: Options): Options["length"] extends number ? string[] : string;

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

The issue simply has to do with that the type seems to favor the left-hand side of the type argument.

Please provide the environment you discovered this bug in

tsconfig: {
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2017",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false,
    "esModuleInterop": true
  }
}

Webstorm 2021.3
VSCode 1.63.2

Anything else?

For some reason, the error does not present itself when run in Code Sandbox with the same tsconfig. However, it has presented itself in two IDE with the above tsconfig.

Do you want to create a pull request?

No

[NetanelBasal]

[kpervin]

https://codesandbox.io/s/hardcore-taussig-p66iu?file=/src/index.ts

[NetanelBasal]

Sure, thanks!

[kpervin]

If you decide to go with the type change, I'd be welcome to open a PR. Otherwise, I'll let you handle the docs.

[NetanelBasal]

I need to understand why it's different in non-strict mode.

[kpervin]

My guess is that if it's not strictly defined as null or undefined, the type inference looks at the definition of Options["length"] rather than the provided value.

[ChrisMancini]

Thanks for discovering the source of this behavior. I too have the same results (and unfortunately the strictNullCheck setting can't be changed on the project I am working on at this time as it will introduce a lot of errors).

What is the recommended course of action? Will strictNullCheck: false be supported in the future?

Thanks!

[NetanelBasal]

We'll add <Options extends FakeOptions = undefined> to support it.

[NetanelBasal]

@kpervin fyi

[NetanelBasal]

Ok, I now see that it fixes the non-strict mode but creates an issue with the strict mode. I'll have to check it.

[NetanelBasal]

@kpervin @ChrisMancini can you please check v2.15.0?

[ChrisMancini]

After upgrading to 2.15.0, I do see the type definition has changed, but I continue to see the return value to be an array if no arguments are passed in.

Here is the type definition for randFirstName (which matches your commit):

export declare function randFirstName<Options extends NameOptions = NameOptions>(options?: Options): Options["length"] extends number ? string[] : string;

[NetanelBasal]

Yes, I see it didn't work.

[NetanelBasal]

@kpervin @ChrisMancini the latest version works fine. (v2.17)

[ChrisMancini]

Thank You!

It looks like randEmail() may have been missed as the type doesn't default to never.