Generate a manifest file per project version

[toddjordan]

This file will be a guide to what files exist in a given project version.

It will be used by the client for 2 purposes:

1. To get a list of files and relationships for the navigation menu, according to https://github.com/ember-learn/ember-api-docs/issues/131
2. To get a list of total files to download via service worker/app cache, according to https://github.com/ember-learn/ember-api-docs/issues/134

I think these might need to be 2 separate files.

One file can list all the files, the other can be used for relationships. Here's a proposal (open for suggestions)

List (manifest.json):

{
       "namespaces": [ { "name": "Ember.FEATURES",
                                      "url": "URL_TO_NAMESPACE_JSON" } ],
       "modules": [ {"name": "ember-debug",
                              "url": "URL_TO_MODULE_JSON"} ],
       "classes": [ {"name":  "Ember.Engine",
                            "url": "URL_TO_CLASS_JSON"} ] 
}

A relationship tree would be interesting... it would be used to populate the left nav and have enough info to specify the route we would go to if we clicked on the item. pre-javascript module rfc Relationships (nav.json):

{
    "packages": [
        {
         "name": "ember",
         "type": "module",
         "children": [
              {     
                 "name": "ember-application",
                 "type": "module",
                 "children": [
                      {
                           "name": "Ember.ApplicationInstance",
                           "type": "class"
                      },
                      {
                           "name": "Ember.ApplicationInstance.BootOptions",
                           "type": "class"
                      },
                      {
                           "name": "Ember.Application",
                           "type": "class"
                      }, ...
                 ]
            }
         ]
    }]

}

This would allow both Classes and submodules/packages to be children, which wouldn't be an issue pre-js module rfc, but would after, and would allow eventually for classes, method, and properties to be listed.

[sivakumar-kailasam]

@toddjordan You can assign this to me since I'm anyway restructuring the folders & generation logic

[toddjordan]

I could be talked out of splitting the manifest.json into namespaces, modules, and classes. We'd be providing this info in the nav.json.

Really the manifest.json would be used for hydrating the cache, and would be store by a key composed of an aggregate project-version-name (and possibly type)

{
       "items": [ { "name": "Ember.FEATURES",
                          "type": "namespace",
                          "url": "URL_TO_NAMESPACE_JSON" },
                       { "name": "ember-debug",
                          "type": "module",
                          "url": "URL_TO_MODULE_JSON"},
                       { "name":  "Ember.Engine",
                         "type": "class",
                         "url": "URL_TO_CLASS_JSON"}
        ]
}

[sivakumar-kailasam]

in its current form a gzipped manifest of ember 2.11 comes up to 1kb. So we might be good for now to stick to the collated form. The manifest contains all the info mentioned in nav.json as well. Here's one in its existing form - https://gist.github.com/sivakumar-kailasam/07f33517f440bfd9a8dc417efa98383d.

[toddjordan]

I don't think that removing classes/namespaces/modules will make it bigger. Looks bigger above because we added type (not sure we'll need yet). I'd rather design the json for use by the client rather than size, as I don't think the peformance difference between 1 and 10kb will be noticable. also, the "types" may change with js modules rfc.

[acorncom]

Fixed by #21