Thank you for that context! As an experiment, I tried modifying the rust implementation to no longer ignore local definitions to learn a bit more.
I see what you’re getting at! I think mostly what I was trying to get at was we could store those definitions in the cache and use them. Then we wouldn’t have to parse everything – we could just pull it in from the cache. Some back of the envelope math says with packs this could be just as fast as building the constant resolver, so I might explore it a bit more.
Very excited to see this! Apologies if this is a silly question, but am I right in understanding that this implementation removes the dependency on packwerk being used in the context of a Rails application? My understanding is that o.g. packwerk boots the Rails app to get the autoloader paths.
I ask, as my company has a Ruby franken-lith. It’s a mixture of grape/sinatra/activerecord/activesupport that is structured very much like a traditional Rails app.
Yes <@U70NN25TNJA> ! Not only do you not need to boot a rails app, but it doesn’t have to be structured like one either. An experimental implementation I’m working on gets definitions directly rather than inferring them from rails auto loaded paths, so it should work on any ruby app.
Would you like to help beta test it? if so let’s chat over DM!
@AlexEvanczuk Fantastic! Definitely interested in playing around with it as a beta test Thinking in public sounds great.
Full context - we’re also in the midst of trying to move our app to use Zeitwerk (it’s been a spiders web of require statements until very recently), so there might be a few wrinkles along the way.
if so let’s chat over DM!
Definitely interested in playing around with it as a beta test 
Thinking in public sounds great.