4 ms·

We are considering allowing the information to be placed in an `install` field in the package.json. Is that something you would prefer?

rubiquity 12y ago
I think that would be a step in the right direction!
- afschwartz 12y ago
  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 https://github.com/HubSpot/offline/blob/master/package.json [2] https://github.com/HubSpot/offline/blob/master/bower.json https://github.com/HubSpot/offline/blob/master/bower.json
eric_bullington 12y ago
YES! A thousand times yes. Please not yet another json file in the root directory. And I say this as someone who is really interested in what you're doing with this.

rubiquity 12y ago

I think that would be a step in the right direction!

afschwartz 12y ago
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 https://github.com/HubSpot/offline/blob/master/package.json [2] https://github.com/HubSpot/offline/blob/master/bower.json https://github.com/HubSpot/offline/blob/master/bower.json

eric_bullington 12y ago

YES! A thousand times yes. Please not yet another json file in the root directory. And I say this as someone who is really interested in what you're doing with this.