[ndbroadbent]

Motivation

Each controller's generated HelperMethods lists every module in its ancestor chain, including all of its parent controller's. Rails calls helper :all on each direct subclass of ActionController::Base (when include_all_helpers is on, the default), so in a typical app every controller below ApplicationController that calls helper or helper_method lists every module in app/helpers. Adding one helper module then rewrites all of those RBIs: in our app, about 50 files.

#225 (2021) went after the same churn by including everything through ApplicationHelper, and was closed as a draft. This takes a different approach, which doesn't depend on any module the app defines.

Implementation

When a controller's parent (the nearest superclass with its own HelperMethods) is a class this compiler generates an RBI for, the controller's module includes the parent's HelperMethods and then only the modules it adds, in the same order as at runtime. Method resolution doesn't change: the modules it no longer lists are ancestors of the parent's module.

A direct subclass of ActionController::Base still lists every module, because the gem RBI for ActionController::Base::HelperMethods can't know the helpers that other gems add to it at runtime.

The parent is found from the class chain rather than from gather_constants, which tapioca dsl SomeController narrows to the requested constants. That keeps tapioca dsl UserController and tapioca dsl generating the same RBI. (Our first version of this, a custom compiler in our app, checked gather_constants and re-listed every module on single-constant runs.)

Tests

• The abstract ApplicationController test's expectation changes: UserController no longer repeats ::ActionController::Base::HelperMethods.
• New: a controller whose parent has no helpers of its own includes its grandparent's module and only the module it adds, not one the grandparent already includes.
• New: the same RBI when only the subclass is requested.

The manual page gets an example.