Modularize Sorcery

[anthonator]

As it stands I use sorcery for about 95% of the projects I work on yet I only use 1/5 of sorcery's capabilities leading to unnecessary bloat in my project's gem dependencies. Moving all the different modules into their own gems would be ideal. With a modular and more developer friendly architecture others will have the opportunity to contribute their own integrations with sorcery as well.

[arnvald]

Hi @anthonator,

I agree with you that architecture should be developer friendly, so that it encourages users to develop and publish their own extensions. We're in process of planning changes for 1.0 release, all contributions and ideas are welcome: http://github.com/sorcery-rails/sorcery/issues

Moving all the different modules into their own gems would be ideal

I disagree. I like small libraries, but I'm not fan of adding new gem in gemfile just to be able to reset user's password. The submodules we currently have are pretty basic, most of them have 150-200 lines (with comments and orm-specific code, which we're going to extract).

unnecessary bloat in my project's gem dependencies

The only Sorcery's dependencies are: oauth, oauth2 and bcrypt. Of course by extracting External submodule we can get rid of first 2, but the other submodules - no gain from extracting them. As far as I understand word "bloat" correctly, I don't think Sorcery adds bloat of dependencies.

[anthonator]

From my perspective I think separating out the submodules is a better solution. That may be personal preference but I find choosing what functionality is relevant for my app desirable. I use sorcery all the time and 95% of the time the only submodule I use is password reset. This doesn't mean the sorcery gem can't be comprised of sorcery-core, sorcery-password-reset, sorcery-whatever. I know Spree uses this model. This also forces you to eat your own dog food in a way and it provides relevant code examples to would-be authors of sorcery extensions. It would also provide a cleaner way for developers to replace common submodules with their own implementations.