Fix several cyclical type imports

[BPScott]

WHY are these changes introduced?

Move us closer to enabling the import/no-cycle rule by fixing several violations.

We can't turn it on just yet, as there's still a few more violations, but I want to chat with @danrosenthal about the best fix for those first.

WHAT is this pull request doing?

Creates per-component types.ts files to contain types in cases that result in cyclical dependencies.

E.g. Consider the following:

// In Component.ts
import {bar} from './utilities.ts';

export interface ThingType {
  x: string;
}

const x = bar({x:'foo'});


// In utilities.ts
import {ThingType} from './Component.ts';

export function bar(thing: ThingType):  {
  return thing.x;
}

In this case Component imports utilities and utilities imports Component - A cyclical dependency. To fix this, introduce a new file that contains the type, and have Component and utilities import from that file:

// In Component.ts
import {ThingType} from './types.ts';
import {bar} from './utilities.ts';

const x = bar({x:'foo'});


// In utilities.ts
import {ThingType} from './types.ts';

export function bar(thing: ThingType):  {
  return thing.x;
}

// In types.ts
export interface ThingType {
  x: string;
}

Now, utilities depends on types, and Component depends on utilities and types. The cycle is removed.

How to 🎩

• Run tests
• Run yarn run sk type-check to prove typescript is happy
• Edit .eslintrc and remove the "import/no-cycle": "off", line and see that the number of warnings is reduced compared to master (should be 26 on master to 14 8 on this branch)

[chloerice]

👏