{"action":"opened","issue":{"url":"https://api.github.com/repos/feathersjs/feathers-hooks-common/issues/31","repository_url":"https://api.github.com/repos/feathersjs/feathers-hooks-common","labels_url":"https://api.github.com/repos/feathersjs/feathers-hooks-common/issues/31/labels{/name}","comments_url":"https://api.github.com/repos/feathersjs/feathers-hooks-common/issues/31/comments","events_url":"https://api.github.com/repos/feathersjs/feathers-hooks-common/issues/31/events","html_url":"https://github.com/feathersjs/feathers-hooks-common/issues/31","id":186713439,"number":31,"title":"Should each hook be in their own repository?","user":{"login":"daffl","id":338316,"avatar_url":"https://avatars.githubusercontent.com/u/338316?v=3","gravatar_id":"","url":"https://api.github.com/users/daffl","html_url":"https://github.com/daffl","followers_url":"https://api.github.com/users/daffl/followers","following_url":"https://api.github.com/users/daffl/following{/other_user}","gists_url":"https://api.github.com/users/daffl/gists{/gist_id}","starred_url":"https://api.github.com/users/daffl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/daffl/subscriptions","organizations_url":"https://api.github.com/users/daffl/orgs","repos_url":"https://api.github.com/users/daffl/repos","events_url":"https://api.github.com/users/daffl/events{/privacy}","received_events_url":"https://api.github.com/users/daffl/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-11-02T05:06:50Z","updated_at":"2016-11-02T05:06:50Z","closed_at":null,"body":"Recently I've been wondering if the best way to maintain this growing number of hooks would be to migrate each one into their own repository/module (potentially in a separate `feathers-hooks` organization):\r\n\r\n- We are already having discussions about major releases related to common hooks. I have the feeling that major versions of this repository could grow very quickly. Updating major versions is a pain for both the maintainers (as I mentioned you have to do more than just make the release e.g. make it public somewhere, document migration, update examples, guides etc.) and users (you have to find out if the version changed, what broke, update your code etc.).\r\n- A breaking major release of `feathers-hooks-common` could be because of an API change of any of the bundled hooks. People will have to go through all the upgrading steps just to find out that they weren't even using that hook.\r\n- There is a chance this repository might become a kitchen sink of hooks that are not related at all (other than they are hooks). Issues can pile up quickly and I think many will be related to the same more complex and most used hooks (e.g. populate).\r\n- It will be easier to split up the documentation into categories since each hook will just be its own module and can be moved around/deprecated/updated independently from each other.\r\n- The only downside I can think of is having to maintain a lot of different modules but we are kind of doing that already. As long as we script repository updates and use the same plugin infrastructure I think we should be good though. In this case we can probably even automate creation by using the GitHub API, initializing a new plugin and copying each hook file and test and publishing it.\r\n\r\n_Alternative:_ Another option would be a monorepo structure like [Babel](https://github.com/babel/babel) but I am not too familiar with that (it seems you will have to automate everything in a very similar way)."}}
{"actor":{"display_login":"daffl"}}