Make DSL generation work with codebases that are not Rails apps

[paracycle]

Tapioca just assumes that the current project is a Rails application and tries to eager load it based on that assumption. However, our DSL generators could work in any codebase, provided that we know how to eager load the project.

We probably need a way for users to tell Tapioca how the codebase should be eager loaded, with the default being the Rails eager-loading that we have in place today.

[jscheid]

As a workaround, create an empty file config/application.rb in the root of your repository and a file config/environment.rb with something like:

# Workaround for https://github.com/Shopify/tapioca/issues/442
Rails = OpenStruct.new(application: OpenStruct.new(config: {}))
require 'file_you_want_processed'

Works with Tapioca 0.10.2

[gshipilov]

My team is working on a non-rails gem that uses protobuf definitions and we're impacted by this. Tapioca doesn't realize that the gem is requiring google/protobuf, and doesn't create stubs for the generated files.

We've found two workarounds to this problem:

1. Run tapioca via ruby -r "google/protobuf" bin/tapioca dsl.
2. (Ab)use the tapioca extensions feature. Creating the file sorbet/tapioca/extensions/protobuf.rb containing just require "google/protobuf" seems to get things loaded correctly.

Neither of these feel particularly great and first-party support for non-rails gems would be welcome.

In general, it would also be great if tapioca supported some mechanism for overriding the autoloading mechanism. We can work around every future autoloading bug if we can give tapioca an explicit set of files to process.