Maintenance: Fix @ts-expect-error strict types

[sheriffMoose]

Closes #20877

What I did

• fixed a few failing types while building sandboxes

How to test

• CI Passes

[shilman]

Why do we need all these extra type annotations? Is it causing a problem without?

[sheriffMoose]

Yes, #20877

[sheriffMoose]

@valentinpalkovic & I are affected, can't do changes without disabling strict mode and do few changes

[yannbf]

I wonder if we should add a TODO comment here to remind to take a look at this code.
if storySort.id can be undefined, it means that the code right after will generate invalid code, e.g.:

return undefined(a, b)

[yannbf]

@sheriffMoose @ndelangen seems like this PR got merged but this was taken into account. Do you think this might bite us back if we don't at least add a TODO there?

[ndelangen]

If you feel like there should be a comment, and you have an idea what that comment should look like, sure.
I don't have a recollection of this context anymore.

[yannbf]

The (now merged) code looks like this:

if (t.isFunctionExpression(storySort)) {
    const { code: sortCode } = generate.default(storySort, {});
    const functionName = storySort.id?.name;
    // Wrap the function within an arrow function, call it, and return
    const wrapper = `(a, b) => {
      ${sortCode};
      return ${functionName}(a, b)
    }`;
    // eslint-disable-next-line no-eval
    return (0, eval)(wrapper);
  }

so if storySort.id is optional, then storySort.id?.name could be undefined, right? meaning that functionName becomes undefined.

later on, return ${functionName}(a, b) will get executed. But then, if functionName is undefined, the evaluated code will be undefined(a,b), which will crash.

[valentinpalkovic]

@sheriffMoose Can you merge the latest next into your branch? If the pipeline is green. Let's merge this. Please take care of Yanns small comment as well.