You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have run into an issue with our usage of Spring (I believe it is the same issue that folks are running in to here: #323). In our case, we have engines inside of an application but we only use a single top-level Gemfile. This has exposed an issue with the order of events when loading of the config/spring.rb.
For us, our config/spring.rb loaded after Spring.application_root_path is memoized and so our config/spring.rb does not have the correct effect.
Here is the issue as I have been able to track it down:
Consider running the command:
bundle exec spring rails runner 'puts :ok'
Spring loads the client/ files and decides it needs to start a server. That eventually leads to spring/commands getting loaded, which loads the config/spring.rb:
This method then hits the default behavior BEFORE Spring has loaded the config/spring.rb. This value is memoized, by the time the config/spring.rb is loaded, its changes to Spring.application_root have no effect.
So, requiring spring/commands somewhere before hitting this line solves the issue:
For those looking for a workaround in the meantime, adding the following to config/spring.rb will fix the issue and make Spring respect your local config/spring.rb in engine dummy apps:
Hi,
We have run into an issue with our usage of Spring (I believe it is the same issue that folks are running in to here: #323). In our case, we have engines inside of an application but we only use a single top-level Gemfile. This has exposed an issue with the order of events when loading of the
config/spring.rb
.For us, our
config/spring.rb
loaded afterSpring.application_root_path
is memoized and so ourconfig/spring.rb
does not have the correct effect.Here is the issue as I have been able to track it down:
Consider running the command:
Spring loads the
client/
files and decides it needs to start a server. That eventually leads tospring/commands
getting loaded, which loads theconfig/spring.rb
:spring/lib/spring/commands.rb
Line 48 in 1f44a26
Spring then decides to spawn a server in the background:
spring/lib/spring/application_manager.rb
Line 96 in 1f44a26
This process spawns and loads this file (note it is in a new process, so it will again need to read the
config/spring.rb
):https://github.com/rails/spring/blob/1f44a267a2476658af86b0bc1afb94588a36ed04/lib/spring/application/boot.rb
The
app.run
on line 19 will lead to the server getting loaded and leads to thespring/commands.rb
getting loaded which loads theconfig/spring.rb
See:spring/lib/spring/application/boot.rb
Line 19 in 1f44a26
BUT, here is the problem, line 15:
spring/lib/spring/application/boot.rb
Line 15 in 1f44a26
This calls
app.app_name
which traces all the way down to the line:spring/lib/spring/configuration.rb
Line 24 in 1f44a26
This method then hits the default behavior BEFORE Spring has loaded the
config/spring.rb
. This value is memoized, by the time theconfig/spring.rb
is loaded, its changes toSpring.application_root
have no effect.So, requiring
spring/commands
somewhere before hitting this line solves the issue:spring/lib/spring/application/boot.rb
Line 15 in 1f44a26
However, based on this line, it seems that we want that to be lazily required, so I'm not sure where exactly the best place to put it would be:
spring/lib/spring/application.rb
Line 86 in 1f44a26
For those looking for a workaround in the meantime, adding the following to
config/spring.rb
will fix the issue and make Spring respect your localconfig/spring.rb
in engine dummy apps:The text was updated successfully, but these errors were encountered: