search

rubyatscale / packs-rails

packs-rails establishes and implements a set of conventions for splitting up large monoliths.
MIT License
268 stars 26 forks source link

Add more detail to engine documentation #87

Closed exterm closed 7 months ago

exterm commented 7 months ago

It previously wasn't clear why you would make something an engine, as this project reimplements part of Rails::Engine's functionality anyway.

The details were stolen from @ngan 's response in https://github.com/rubyatscale/packs-rails/discussions/14.

This still seems a little bit like bending over backwards to me; why isn't every pack an engine by default? Namespace isolation is just one of many engine features and could be off by default.

professor commented 7 months ago

why isn't every pack an engine by default?

I like this question. Perhaps by default each pack should be an engine which is a great fit for a new code base. For an existing monolith, it's nice to do incremental modularization, so overwriting the default would be an option.

ngan commented 7 months ago

Hey guys, when I first wrote stimpack (now just packs) I added the option to make packs engines so that we were backwards compatible with our existing in-repo engines (aka components). I actually didn’t like that I had to do this which is why I didnt document the feature.

I think the reasoning was that engines are more powerful than what we actually needed (or even wanted). The hidden/metaprogrammed engine class was a bit weird to me as well, and didn’t work well with Sorbet. I actually wanted to remove the engine feature at some point.

Anywho, I’m not sure what my stance is nowadays because I haven’t thought much more about it. We are actively trying to remove our components at Gusto and move them into packs, which would make them less capable…but to me that’s a feature and not a bug.

exterm commented 7 months ago

I'm personally of the opinion that packages and gems should be part of a continuum, and the way to make that work in Rails is engines. There is no good documentation on this but engines can be stripped down to only do what you need - e.g. just setting up autoload paths at first. Selectively loading packages can then be done via bundler and package gemspecs. That way you can stay much closer to established ruby and rails tooling and conventions than what packs-rails is currently doing.

There's some discussion about this in https://github.com/Shopify/packwerk/discussions/361.