change default ThunkArg of cAT to OptionalUnknown

[phryneas]

Since TypeScript 4.0, the following example will cause an error when checking JavaScript files (with allowJs & checkJs):

const thunk = createAsyncThunk('', arg => {})
thunk()
// @ts-expect-error Expected 0 arguments, but got 1.ts(2554)
thunk('something')

The only way around that without breaking too much explicit existing behaviour is this type "OptionalUnknown".
On the flip side, using a payloadcreator without a defined argument, like

const thunk = createAsyncThunk('', () => {})

will now generate a thunk that can optionally be called with any first argument opposed to a thunk that would not accept any argument before.

This is not nice, but there's not much way around it without significantly changing createAsyncThunk types that are public. (And even then I'm not sure if I could find a better solution).
This is a change as well, but only one that will lead to more relaxed typechecking, so nobody upgrading should get any errors.

@markerikson, opinions on this?

[markerikson]

So the only issue here is TS compat with checkJs files?

That doesn't seem like it's worth us spending much effort on, tbh - I'd rather have better types in TS files.

[phryneas]

Might be affecting JS typehints in VSCode in general as well. My testing on that has been a little unconclusive.

[markerikson]

I'm just really hesitant to do any changes that weaken the actual TS support for the purposes of semi-typed-JS interop :)

[phryneas]

Hey, have you become me now, or what? :D

It's not that bad, so I'd kinda, grudgingly be okay with it:

But I'll try and investigate if this also occurs like, in a blank CRA JS installation.

[phryneas]

Okay, blank CRA JS seems unaffected.
So, make a draft PR out of this and see if multiple real people are actually affected by this?
So far, I've only seen the case in one stackoverflow question.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 6753973:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration
rsk-github-issues-example	Configuration

[phryneas]

Just some more experimentation:

• this also happens when adding // @ts-check to a .js file
• this also happens when adding a jsconfig.json with

{
  "compilerOptions": {
    "moduleResolution": "node",
    "target": "es6",
    "checkJs": true
  }
}

to the project.

This can be fixed in the code by providing a type for the argument via

const thunk2 = createAsyncThunk(
  "",
  /**  @param arg {string} */
  (arg) => {
    console.log(arg);
  }
);
// @ts-expect-error Expected 1 arguments, but got 0.ts(2554)
thunk2();
thunk2("something");

Especially the jsconfig.json bit is something that I would actually for a chunk of projects in the wild to use.
But probably by people who want the additional type safety - so maybe it would even be good for them to use it with that type annotation?

So we could alternatively go the way of documenting this. But I wouldn't really know where to put this.

[phryneas]

This also goes for #680, which we can't really fix in types. We also cannot detect if the current file is being run in TS or JS and act accordingly.

[markerikson]

I'm still not really clear on what the status of this one is :)

[phryneas]

Could be cool, could be uncool, not really sure how many people it would affect.
We should probably at least add documentation on how to get around it with JSDoc at some point.
Either way: no need to rush a decision for 1.5