--noImplicitAny codefixes infer anonymous object types despite appropriate interfaces in (or out of) scope

TypeScript Version: 3.3.0-dev.20181212

Search Terms: noimplicitany infer code fix codefix quick suggested

Code

interface IBox {
    x: number;
    y: number;
}

const shiftBox = (box) => {
    box.x += 1;
    box.y += 1;
}

const box = {
    x: 0,
    y: 0,
};

shiftBox(box);

Expected behavior:

--noImplicitAny suggested fix on the box parameter:

const shiftBox = (box: IBox) =>

Actual behavior:

const shiftBox = (box: { x: any; y: any; }) => {

Related Issues: #13243 (parent tracking quick fixes) and #15114 (discussion on inference difficulties)

If there is an interface available that can satisfy an inferred type in a --noImplicitAny code fix, can we use that? Perhaps with an ordering of possibilities like:

1. Interfaces already available in the file, by how small they are
2. User-defined interfaces that could be imported, by how distant the file is
3. Module types already imported in a user file, by how distant the nearest import is

...where, if multiple interfaces could satisfy the best possibility of those three, we choose the one with the fewest fields?

In code bases that don't explicitly type when unnecessary (e.g. : IBox for variables), I'm finding the --noImplicitAny fixes to be a bit useless for anything other than primitives.

Beginnen Sie mit dem bereitgestellten TypeScript-Beispiel und reproduzieren Sie die Ausgabe des --noImplicitAny-Codefixes. Lesen Sie die Diskussion in den verwandten Issues #13243 und #15114, um die vorgeschlagenen Regeln zur Interface-Auswahl zu verstehen; als erledigt gilt die Aufgabe, wenn ein kompatibles verfügbares Interface wie IBox gegenüber einem anonymen Objekttyp bevorzugt wird, ohne andere Codefix-Fälle zu beeinträchtigen.