search

fastruby / next_rails

A toolkit to upgrade your next Rails application
https://www.fastruby.io/blog/upgrade-rails/dual-boot/dual-boot-with-rails-6-0-beta.html?utm_source=github&utm_medium=description&utm_campaign=github&utm_term=next-rails
MIT License
482 stars 31 forks source link

support spring #28

Open timdiggins opened 2 years ago

timdiggins commented 2 years ago

Thanks for the work on this fork/gem.

I think that currently commands like next rails c when you have "springified" your rails will cause errors, or will always invoke the previous rails rather than the current one. I think this is a matter of making the ENV var changes exported from the next.sh script in line 39

https://github.com/fastruby/next_rails/blob/3c99380da9aa5f4ecbb3444f9794c721b2d40b7c/exe/next.sh#L39

ie. changing this to

    export BUNDLE_GEMFILE=Gemfile.next BUNDLE_CACHE_PATH=vendor/cache.next 
    bundle exec $@

This is quite a small change so it might be easier if a committer did it, but happy to contribute a PR.

timdiggins commented 2 years ago

Actually I've just tested this out and my theory seems to be wrong. You need the export BUNDLE_GEMFILE=Gemfile.next in the calling shell (where you type next rails c or whatever) -- doing it within next.sh, doesn't fix the issue with spring.

It would still be good to support spring automatically (you still need to manually start and stop spring) but for now the workaround seems to be to export BUNDLE_GEMFILE=Gemfile.next rather than (or in addition to) using next

fbuys commented 1 year ago

I have seen a similar thing.

I have never tried to determine the steps to replicate this issue. Does anyone have the steps to replicate it?