bugfix: duplicate properties (#276)

[jenweber]

Addresses #276

Whenever there are duplicate methods, the first one in the filtered list is the "most local," as far as I can see. If I'm reading the code right, it appears that this is how it was handled in the past as well.

One piece is missing: What would a good test be? It would be easy to write a test that asserts that there aren't duplicates, but I'm most concerned about the source data ordering changing somehow and that not being caught, resulting in the "less specific" documentation being shown. Suggestions? I can add a test before a merge. I'm PR'ing it now for easy testing/comparison/advice by a reviewer.

cc @sivakumar-kailasam @toddjordan

[sivakumar-kailasam]

@jenweber Looking at a shorter version of the response data from server for json api adapter, one case where we see duplicates, it looks like we have an extra piece of information we could use to figure out the most local entity with confidence.

Short JSON API doc

{
  "data": {
    "id": "ember-data-2.14.6-DS.RESTAdapter",
    "type": "class",
    "attributes": {
      "extends": "DS.Adapter",
      "file": "addon/adapters/rest.js",
      "uses": [
        "DS.BuildURLMixin"
      ],
      "methods": [
        {
          "name": "createRecord",
          "file": "addon/adapters/rest.js"
        },
        {
          "name": "createRecord",
          "file": "addon/adapter.js"
        }
      ]
    },
    "relationships": {
      "parent-class": {
        "data": {
          "id": "ember-data-2.14.6-DS.Adapter",
          "type": "class"
        }
      },
      "descendants": {
        "data": [
          {
            "type": "class",
            "id": "ember-data-2.14.6-DS.JSONAPIAdapter"
          }
        ]
      },
      "module": {
        "data": {
          "id": "ember-data-2.14.6-ember-data",
          "type": "module"
        }
      },
      "project-version": {
        "data": {
          "id": "ember-data-2.14.6",
          "type": "project-version"
        }
      }
    }
  }
}

The module has a file attribute that is also present in the event/methods/properties model. May be grouping by name and picking the one with the same filename as module, if not the filename of the base class of the module & so on(unsure if this extended use case exists) might be more accurate.

On the matter of tests, may be an acceptance test would suffice. We could probably use the rest adapter or something similar to verify unique items & their sources (may be data-test-file to indicate their source?)

Sorry I couldn't put up this info sooner, hadn't investigated this issue until now 🙁

[jenweber]

Don't merge yet. This needs another careful code review and a test.

[sivakumar-kailasam]

@jenweber I merged from master so that we could see your changes on the review app. Added a WIP prefix to keep us from hitting that green button :)

[jenweber]

@sivakumar-kailasam ok good, you were making me nervous, haha

[sivakumar-kailasam]