This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
<@U70NN25TNJA> <@U72GGKIGPTW>
I added the APIs as discussed above! You can get it by updating with cargo install pks.
You can check out the updated docs in the EXPERIMENTAL_PARSER_USAGE.md doc.
Let me know what ya think!
Message originally sent by slack user U70NN25TNJA
Hey Alex! 
This all looks great. We ran it in a “proper” Rails app, and our frankenlith, and it met our expectations. Of note, list-definitions --ambiguous was nice as it found some weirdness in tests that was really not visible otherwise.
Another thing we noticed is that the experimental parser is finding more stuff in some circumstances than the ‘classic’ parser in a standard Rails application. It seems to be related to includes, and associations.
Experimental:
packs/some_pack/app/models/foo.rb:11:10
Dependency violation: `::Bar` belongs to `.`, but `packs/some_pack/package.yml` does not specify a dependency on `.`.
Classic:
No violations detected!
We’re not complaining as this seems like an improvement, but thought we should mention it.
One last note - as you are adding new features we will definitely need to declare custom associations. Our monolith (sadly) uses Mongoid, so we have things like embedded_in, et al. We would love to test this out whenever it’s ready! 
Nice! Yeah, I feel like there are a lot of interesting possibilities to enforce conventions around defining modules / monkey patching or not monkey patching other classes/ etc. using some of this tooling.
There will definitely be a handful of ways in which the experimental parser will find more things! Besides being able to load constants that are not autoloaded with zeitwerk, during development I noticed some things that packwerk misses. Also inflections/associations etc. have lots of edge cases in loading the constant so I wouldn’t be surprised if packwerk missed them.
I just added custom associations. It should use the same API described in the packwerk readme. Let me know how it goes!
You can update with cargo install pks as always
Message originally sent by slack user U70NN25TNJA
Amazing! Thanks so much for the fast turnaround! 
We noticed one difference from the Ruby packwerk implementation of this. In Ruby-land, they’re declared as quasi-symbols in yaml, e.g.:
custom_associations:
- :embeds_many
- :embedded_in
Whereas the rust implementation seems to need them defined as plain strings, e.g.:
custom_associations:
- embeds_many
- embedded_in
Although the latter is a little nicer, thought we’d mention it if you want to go for backwards compatibility with the existing implementation.
If you could do it either way, that’d be 
!
Message originally sent by slack user U70NN25TNJA
Oh yeah, and we tested it and it works great
Thanks for the feedback! I just made that update so it should now accept symbols now
Is there anything else missing that is blocking you?
Message originally sent by slack user U70NN25TNJA
We’re gonna do a more formal comparison soon, but off the top of our heads there doesn’t seem to be anything glaringly missing. As mentioned before, some of the nice shortcuts from use_packs (e.g. add_dependency et al) would be super nice-to-have, but shouldn’t be a blocker for us beginning to experiment as we’re planning on rolling the tooling out very gradually. We have one term with custom inflections, but that isn’t be something we’ll be tackling in the immediate future.
We’re very keen to try it though, as it should avoid the need for us to write weird shim to replicate exposing Rails’s autoloader stuff.
A general question I guess - what’s the plan for longer term support of this library? Is this something that Gusto is committed to maintaining? This is more for us being able to make the powers-that-be happy over here
Message originally sent by slack user U70NN25TNJA
(the update to custom_associations worked great, thanks for the support of with and without symbols! 
)
Sounds good – definitely let me know what the comparison turns up.
As far as longer term support goes, my current hope is that I’ll be able to maintain it. This would mean supporting essential updates (for example, a security update, updating the ruby parser dependency for new Ruby APIs, etc. etc.) as well as net-new features that feel maintainable. More generally, as folks use this I hope some folks in the community would be interested in helping to maintain it.