While I fully support the ability of using an `install` property in a `package.json` as an alternative, as a frequent author of package.json, bower.json, component.json, and install.json files, I feel confident saying that install.json is a slightly different situation. Take github.com/HubSpot/Offline for example:

The package.json [1] and bower.json [2] share a lot of the same information: `name`, `version`, `authors`, and `description` are duplicated properties in both. Furthermore, updating the `version` property in a file in Git isn’t always necessary when you can create tagged releases with version numbers.

`install.json` doesn’t have the “Ugh, now I have to add the same information in a new place”-problem because it introduces two new root properties, namely `resources` and `options`, which do different (and very useful) things from the properties in these other json files. These properties define respectively the resources to include in a page when “installing” the app, and the JSON options to provide the app upon its initialization. They allow for a common way that JS and CSS resources be included in pages, which is a useful thing for the community to start to standardize around, even if this isn’t the perfect thing yet.

[1] https://github.com/HubSpot/offline/blob/master/package.json

[2] https://github.com/HubSpot/offline/blob/master/bower.json