Closed mpace965 closed 3 months ago
TIL. Thanks for the PR @mpace965!
@mpace965 I ended up hunting around for yet a third option to facilitate this, as the previous method of setting the IRB WorkSpace binding was making the prompt in the console look really weird (it was a long Bridgetown classname instead of main
). Take a look at my fix here: https://github.com/bridgetownrb/bridgetown/commit/dc08da22084dee5dc5d4d828d0c0e171ce0ec0c4
It seems like that still facilitates your example of using cws
but if you think there's any issue let me know. Thanks!
If you were trying out the cws
command in IRB, that is probably what was causing the Bridgetown class name to show up instead of main
. That is actually native functionality of IRB, unrelated to this change. That part of the prompt indicates the current workspace (which the cws
command changes).
That being said, it looks like defining the methods that way works just as well! Thanks for taking a look.
This is a 🐛 bug fix.
Summary
Move the
site
andcollections
console commands to be local variables in the IRB shell.Context
Console methods have precedence over Ruby methods with the same name. This means that any method name or local variable will be clobbered by the IRB commands
site
andcollections
. This presents an issue when using the IRB or Pry object navigation features, e.g.In this example, I've tried to execute
Bridgetown::Site#render
after setting the IRB workspace tosite
. This results in aSystemStackError
because when callingcollections
on this line, thecollections
IRB command is executed instead of thecollections
instance method onsite
.This PR moves
site
andcollections
to local variables that are passed into the main IRB workspace as a binding. This does mean that over the course of an IRB session, a user is free to initializesite
orcollections
to something else. The upshot is that there's no longer a risk of clobbering these method names.