Isolated declarations inconsistent about banning default assignment patterns for function parameters about typescript HOT 2 CLOSED

I opened #58637. This PR ensures we give errors for function declaration/class methods as well. It also only errors if the type doesn't syntactically contain undefined, and if the type can't be proven to not contain undefined. This means that number[] or T | undefined will not error, since for the first we know it does not contain undefined (so we could add it) and for the second we know it does. The only case that will error is where the type of the parameter is a type reference such as T for which we would need to lookup type information to determine if it contains undefined or not.

There is an argument to be made that this need not be an error at all. If we always add | undefined one of two things can happen: either T already contains undefined and thus the extra union is redundant but semantically equivalent, or T does not contain undefined in which case it should have been added. This does create a situation where if we align emit, TSC will seem silly. The bugs write themselves: Why is TS not smart enough to realize that T already has undefined in it and is adding this redundant union to my parameter type.

I would be happy if we were to not need an error here. @weswigham do you think adding | undefined to the type regardless would be a big source of bugs with resolution: "we did this intentionally"?

from typescript.

Obviously it's semantically equivalent to add an | undefined onto a type that already has an undefined, so it'd do nothing. But at the same time, we don't have a good reason to regress our emit and blindly add | undefined in all cases. It should certainly be fine for an emitter to do so, and should simplify things for it greatly, but we don't have a reason to do so in the general case. transpileDeclaration might need to, since it has to handle non-resolving type nodes that it can't determine the undefined-ness of, but I can't really see a compelling reason to adjust normal declaration emit output. It'd just produce stuff like Alias | undefined even when type Alias = Foo | undefined, which just.... isn't gonna feel great.

So I can see adjusting the fallback behavior for non-resolving types to be adding | undefined to the existing node - that'll probably help transpileDeclaration. I'm just less sure about changing the behavior more broadly. We've said a couple times that while we're happy to take improvements to declaration emit that happen to cause alignment (preserving original intent more by copying more nodes as originally written being the big one), we're not really interested in making our normal output match 1:1 with what something limited could produce just for the sake of it.

from typescript.