fix(#20846 lib/es2015): override new Proxy<T, U>

[IgorNovozhilov]

Fixes #20846

Faced with the need to definition type the Proxy output in my project, I got acquainted with the problem #20846.
I suggest the following solution using overloads, preserving the health of the current behavior and backward compatibility with the current definition format

example:

interface XProxyConstructor {
  revocable<T extends object>(target: T, handler: XProxyHandler<T, any>): { proxy: T; revoke: () => void; };
  revocable<T extends object, U extends object>(target: T, handler: XProxyHandler<T, U>): { proxy: U; revoke: () => void; };
  new <T extends object>(target: T, handler: XProxyHandler<T, any>): T;
  new <T extends object, U extends object>(target: T, handler: XProxyHandler<T, U>): U;
}
declare var XProxy: XProxyConstructor;


interface A { a: string }
interface B { b: number }

const a: A = { a: '' }

var b = new XProxy<A, B>(a, {})

in VSCode

[dominikdosoudil]

@IgorNovozhilov interface B states that proxy instance has member b but it will be undefined since you are not implementing get method in proxy handler imho. Isn't that right? I think that handler implementation should be checked somehow too.

[IgorNovozhilov]

@dominikdosoudil get?<K extends keyof U>(target: T, p: K, receiver: U): U[K];
see https://github.com/microsoft/TypeScript/pull/44458/files#diff-b75b6262c7b08c14e3021895c9cec18fb5c6ba7ae2eadfa64ee4bd6b14b8018bR6
however, presence get handler is optional

[dominikdosoudil]

@IgorNovozhilov Yeah, get is optional. That's the problem. You are showing that b.b is number in the first screenshot. However it will be undefined since get is not provided.

interface A { a: string }
interface B { b: number }

const a: A = { a: '' }

var b = new XProxy<A, B>(a, {})

b.b // undefined because 'get' not provided in handler however your typing says it will be number

[orta]

I'm pretty hesitant on this PR, because every time we've introduced extra generics like this into the stdlib a lot of things break unexpectedly. Let's see what happens with the larger test suites.

@typescript-bot test this
@typescript-bot run dt
@typescript-bot user test this

[typescript-bot]

Heya @orta, I've started to run the parallelized Definitely Typed test suite on this PR at 5510089. You can monitor the build here.

[typescript-bot]

Heya @orta, I've started to run the extended test suite on this PR at 5510089. You can monitor the build here.

[typescript-bot]

Heya @orta, I've started to run the parallelized community code test suite on this PR at 5510089. You can monitor the build here.

[dominikdosoudil]

@orta Members (and their types) of Proxy depend on its constructor arguments so it cannot have other than generic typing.(any should not be used) So replacing the any type of get arguments is basically the correct way.

However I've shown the bug that brings this PR so I think that there is no point in running tests because if they pass, there is still obvious issue.

[typescript-bot]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[gabritto]

I think we need more tests to be able to reason about how that change would work. If you could add the tests I mentioned in comments, that would be a great start. Thanks.

[gabritto]

can you add a test for the program in the original bug? (#20846)
I don't understand how inference of U would work to fix the bug for that program, since in that case there is no receiver.

[gabritto]

I can't immediately see how this ordering of overloads would work. Could you add tests where TypeScript choses one vs the other overload signatures?

[gabritto]

For future reference: if we want to move on with this PR, we should test this with vue and jsdom, which seem to be the only big users of Proxy.

[sandersn]

@IgorNovozhilov Do you want to keep working on this? Otherwise I'd like to close it to reduce the number of open PRs.