Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more detail to engine documentation #87

Merged
merged 1 commit into from
Mar 15, 2024

Conversation

exterm
Copy link
Contributor

@exterm exterm commented Mar 11, 2024

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 #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.

It previously wasn't clear why you would make something an engine, as this project reimplements part of Rails::Engine's functionality anyway.
@professor professor merged commit 1be1086 into rubyatscale:main Mar 15, 2024
@professor
Copy link
Contributor

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
Copy link
Collaborator

ngan commented Mar 15, 2024

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
Copy link
Contributor Author

exterm commented Mar 18, 2024

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 Shopify/packwerk#361.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants