Suggestion: Use an opt-in approach for compilers

[andyw8]

👋 I'd like to propose that all, or at least some, compilers offered through boba should be opt-in.

(Note: I work at Shopify but this is related to personal work).

Let's say I'm using paperclip and want to use the compiler offered by boba.

If I run tapioca dsl, I'll get the definitions for paperclip, but also for 'opinionated' compilers such as ActiveRecordColumnsPersisted and ActiveRecordAssociationsPersisted.

Currently, I can opt-out of these one-by-one via Tapioca's config, but when new compilers are added to boba then I may need to update that list.

Any thoughts?

(I understand that to implement this might require upstream changes in Tapioca).

[stathis-alexander]

Hey @andyw8 , thanks for the feedback.

In the Usage section of the readme, we suggest using the only: configuration in the tapioca config to define exactly the compilers (from tapioca or boba) your project uses or needs. This is how we configure the opt-in behavior here at Angellist.

I agree that modularity here is a core feature, I just haven't thought deeply about how it would be configured from the Boba side. Tapioca is a bit rigid about how it loads compilers (it eager loads all compilers in a rather fixed set of paths), so the gem is setup so that they're autoloaded by default and then it's on the consumer to configure which ones they want. This feels like more a feature / aspect of tapioca than of Boba.

I am personally open to changing this behavior so that it works better, but I'm not sure how best to approach it. If you have a good idea for how this configuration could be better achieved, I'd love to hear it!

[andyw8]

Thanks, I had missed that part in the README. I'll have a think about how we could have it be the default.

[stathis-alexander]

One possible idea is that we could update Tapioca's config to follow a similar method to Rubocop. It's a bit of an undertaking, however.