search

rubyatscale / packs-rails

packs-rails establishes and implements a set of conventions for splitting up large monoliths.
MIT License
268 stars 26 forks source link

Trouble with spring after moving / renaming packages? #81

Closed exterm closed 7 months ago

exterm commented 8 months ago

We're running into situations where packwerk check or packs check returns incorrect results in some situations, like after changing branches. I believe that this is due to an interaction (or lack thereof) between packs-rails and spring.

Is anyone else seeing this problem?

I just (seemingly) fixed this on a project I am working on.

It looks like the explanation is the following:

packs-rails sets up autoload paths by detecting package.ymls. So moving packs around, renaming them, deleting packs or creating new ones leads to the autoload paths being changed. The application has to be restarted for that. Which means spring needs to watch all the package.ymls. I just did a Dir["packs/**/package.yml"],each { |f| Spring.watch(f) } to fix it for us.

But if this is the actual explanation, everybody setting up packs-rails naively should have this problem, and I haven't been hearing much about it. Does this ring a bell for anyone?

If this is actually a common problem, maybe we can have packs-rails set up the spring watches implicitly?

professor commented 8 months ago

We've experienced this too in the past, but less so now.

Our main code project now automatically does a bin/spring stop whenever we change branches.

We like your solution and started implementing it but ran out of time during ensemble pairing. https://github.com/rubyatscale/packs-rails/pull/82 -- we confirmed that the after initiailzer is correctly adding each package.yml file but did not see spring restarting itself with bin/spring status -- hope to continue this work next week.