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

Prototype for custom app loaders #912

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Prototype for custom app loaders #912

wants to merge 3 commits into from

Conversation

Morriar
Copy link
Collaborator

@Morriar Morriar commented Apr 28, 2022

Motivation

Currently Tapioca is unable to generate DSL RBIs for applications that are not Rails applications.

This PR provides a way for the user to pass a custom loader so Tapioca can load the application then run the RBI compilers.

To do so, one can create a file under sorbet/tapioca/loader.rb with the following content:

Tapioca.load_for_dsl do
  print "Loading my custom application application..."
  require_relative "../../lib/post.rb"
  puts " Done"

  load_dsl_compilers
  require_relative "../../lib/compilers/some_custom_compiler.rb"
end

Tests

See automated tests.

@Morriar Morriar requested a review from a team April 28, 2022 21:29
@Morriar Morriar self-assigned this Apr 28, 2022
Morriar and others added 3 commits April 28, 2022 17:31
Signed-off-by: Alexandre Terrasa <[email protected]>
Co-authored-by: Ufuk Kayserilioglu <[email protected]>
Signed-off-by: Alexandre Terrasa <[email protected]>
Co-authored-by: Ufuk Kayserilioglu <[email protected]>
Signed-off-by: Alexandre Terrasa <[email protected]>
Co-authored-by: Ufuk Kayserilioglu <[email protected]>
@vinistock
Copy link
Member

About the user experience, is there a simple way we could detect if the developer forgot to invoke load_dsl_defaults?

One idea I had, but that requires changing the interface, would be separating loading the app from loading custom compilers and having Tapioca deciding when to invoke load_dsl_defaults. E.g.:

Tapioca.eager_load_app do
  require ...
end

Tapioca.load_dsl_compilers do
  require ...
end

# And then, inside Tapioca
def execute
  instance_exec(&Tapioca.eager_load_app_block)
  load_dsl_defaults
  instance_exec(&Tapioca.load_dsl_compilers_block)
end

WDYT?

Copy link
Member

@paracycle paracycle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have 2 problems with this but I think we should merge the PR so that we can iterate on those separately:

  1. I don't like the fact that we are basically exposing the Dsl command's surface area as a public API to the loader file. This will cause us problems down the line, since the command looks like an implementation detail to us devs, but will now be a public API where we can't change some method names/signatures anymore. Ideally, we would expose the surface area of a specific and custom object, something like a DslLoaderApi class or something.
  2. I am not a fan of the DSL language we are building inside the loader and have similar concerns with @vinistock about how easy it might be to make people shoot themselves in the foot.

However, we can iterate on these, so LGTM.

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

Successfully merging this pull request may close these issues.

3 participants