-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add spring watch #82
Add spring watch #82
Conversation
lib/packs/rails/railtie.rb
Outdated
puts "Hello Db Blasters!" | ||
Packs::Specification::Configuration.fetch.pack_paths.each do |dir| | ||
puts "#{dir}" | ||
Dir["#{dir}/package.yml"].each { |f| |
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.
why would you do a glob here (Dir[]
)? Isn't dir
the exact path? In which case you'll want File.join(dir, "package.yml")
or something like that
But I'm probably misunderstanding pack_paths
...
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.
Great question!
Example pack_paths
:
packs/*
packs/*/*
We need Dir[]
to get the full paths to package.yml
files
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.
ah, makes sense!
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 think pack_paths
is easy to misunderstand; it's more like pack_path_specs
or pack_path_globs
, but that's out of scope here
When a pack moves, we want spring to update the loaded classes so that packwerk prints correct results Co-authored-by: Teal Stannard <[email protected]> Co-authored-by: Ashley Willard <[email protected]> Co-authored-by: Joey Schoblaska <[email protected]>
Co-authored-by: Ashley Willard <[email protected]> Co-authored-by: Joey Schoblaska <[email protected]> Co-authored-by: Perry Hertler <[email protected]>
acd06a7
to
35e6731
Compare
Co-authored-by: Todd Sedano <[email protected]> Co-authored-by: Teal Stannard <[email protected]> Co-authored-by: Perry Hertler <[email protected]> Co-authored-by: Ashley Willard <[email protected]>
Very excited for this to land |
One note: this doesn't seem to cover the case where an autoload path is added and none of the previously registered I just added an initializer to a pack and had to stop spring manually. |
Thanks for the comment! We want to clarify the expectation. Did you add a new autoload path or a new file in the autoload path? We noticed that Spring has a limitation on only watching files it knows about when initialized. New files, including ruby files, will not cause Spring to reload. |
Co-authored-by: Ashley Willard <[email protected]> Co-authored-by: Joey Schoblaska <[email protected]>
f115e2a
to
99e9669
Compare
Mmmh, was that with or without https://github.com/rails/spring-watcher-listen ?
https://github.com/guard/listen?tab=readme-ov-file#features And here's the code in
If I remember correctly, I added a pack with new ruby files and didn't modify any existing package.yml files. In general - why would we expect this mechanism to be able to pick up new autoload paths from newly added packages? We only respect I wonder if we could listen to additions of package.yml files... but it seems that would require a custom spring watcher, or modifications to |
Replaced by #86 |
Pull request was closed
The other PR says this was closed because it "started to need more and more gem dependencies". I don't see those in the diff. Can you expand on the problem you encountered? |
When a pack moves, we want spring to update the loaded classes so that packwerk prints correct results
Fixes #81