[CHORE] redivide assets to move record-data into package

[runspired]

Types are hard :(

A few notes:

TS Config Pains

• whatever package you open first in vscode is the tsconfig.json that applies to the rest
• the -ember-data tsconfig.json is what is used when running tests and applied to all packages
• running tsc (as we do during CI and release) correctly uses the appropriate tsconfig.json for each package

This is gnarly and leads to a horrible experience. We should refactor to a single root tsconfig.json and teach ember-cli-typescript how to find it.

Circular Types & Imports

• some interfaces were refactored and a new technique for type import was introduced to handle issues around circular type imports between the store and record-data packages. As we further refactor away from internal-model we should be able to eliminate much of this weirdness.
• a few utils are now duplicated in record-data / store to avoid circular imports (relationshipStateFor coerceId)

DefaultRecordData

We now wire RecordData in via the ember-data/store for apps consuming ember-data. "BYOPackages" mode requires doing the same.

[chriskrycho]

I'm happy to help tweak the experience for making sure it works well for VS Code – it'll be relatively straightforward, and it'll be useful prior art for other projects I'm working on. The two approaches that should Just Work™ are:

• Create VS Code workspace and open that instead of opening individual packages.
• Create a root tsconfig.json and have the other tsconfig.json files extend from it. The bits that matter for ember-cli-typescript should all still work as expected, since the specific mappings it sets up are not used for transpilation, only for type resolution.

[chriskrycho]

Had a couple catches and a bunch of questions.

I also have one possible step toward working around the current issues with recordDataFor:

I have a type workaround that makes recordDataFor work, and if we adopt it we'll probably want to use its workaround in these types as well. Supplying that workaround will almost certainly catch bugs – it did catch them in core-store.ts.

recordDataFor workaround implementation

import RecordData from "../ts-interfaces/record-data";

// These types exist to support the backwards-compatible, "loose" lookup below.
type WithPrivateInternalModel = { _internalModel: { _recordData?: RecordData } };
type WithPublicInternalModel = { internalModel: { _recordData?: RecordData } };
type WithRecordData = { _recordData?: RecordData }

type Instance =
  | WithPrivateInternalModel
  | WithPublicInternalModel
  | WithRecordData;

/*
 * Returns the RecordData instance associated with a given
 * Model or InternalModel.
 *
 * Intentionally "loose" to allow anything with an _internalModel
 * property until InternalModel is eliminated.
 *
 * Intentionally not typed to `InternalModel` due to circular dependency
 *  which that creates.
 *
 * Overtime, this should shift to a "weakmap" based lookup in the
 *  "Ember.getOwner(obj)" style.
 */
export default function recordDataFor(instance: Instance) {
  let internalModel =
    (instance as WithPrivateInternalModel)._internalModel ||
    (instance as WithPublicInternalModel).internalModel ||
    instance;

  return internalModel._recordData || null;
}

errors in core-store.ts

../store/addon/-private/system/core-store.ts:1630:44 - error TS2531: Object is possibly 'null'.

1630             data: internalModels.map(im => recordDataFor(im).getResourceIdentifier()),
                                                ~~~~~~~~~~~~~~~~~

../store/addon/-private/system/core-store.ts:1630:62 - error TS2339: Property 'getResourceIdentifier' does not exist on type 'RecordData'.

1630             data: internalModels.map(im => recordDataFor(im).getResourceIdentifier()),
                                                                  ~~~~~~~~~~~~~~~~~~~~~

../store/addon/-private/system/core-store.ts:1708:41 - error TS2531: Object is possibly 'null'.

1708         let response = internalModel && recordDataFor(internalModel).getResourceIdentifier();
                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../store/addon/-private/system/core-store.ts:1708:70 - error TS2339: Property 'getResourceIdentifier' does not exist on type 'RecordData'.

1708         let response = internalModel && recordDataFor(internalModel).getResourceIdentifier();
                                                                          ~~~~~~~~~~~~~~~~~~~~~

../store/addon/-private/system/core-store.ts:3101:5 - error TS2322: Type 'RecordData | null' is not assignable to type 'RecordData'.
  Type 'null' is not assignable to type 'RecordData'.

3101     return recordDataFor(internalModel);
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At a minimum, even if it's not possible to adopt that type (and expansions of it in calling contexts) for now, you may be able to use it to chase down possible source of bugs, as in the cases I caught here.

[chriskrycho]

[Gaurav0]

Applications shouldn't have to know about these sorts of details of ember-data.