-
Notifications
You must be signed in to change notification settings - Fork 125
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
base: main
Are you sure you want to change the base?
Conversation
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]>
About the user experience, is there a simple way we could detect if the developer forgot to invoke 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 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? |
There was a problem hiding this 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:
- 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 aDslLoaderApi
class or something. - 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.
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:Tests
See automated tests.