Remove spring-watcher-listen from default Gemfile

[y-yagi]

spring-watcher-listen watch application root by default.
https://github.com/jonleighton/spring-watcher-listen/blob/c4bfe15805867e229588e4b776a7b87438137094/lib/spring/watcher/listen.rb#L58

This is necessary to watch the file (e.g. .ruby-version) in the application root.

By this node_modules also be watched, and it is a possibility to be
shown a warning by listen.
Related to #32700, #34912, rails/webpacker#1990.

listen watches directory recursive by default, and it cannot avoid it.
guard/listen#111
So If this warning happens, the only workaround the user can do is remove the gem.

The issue is likely to occur more frequently in Rails 6 because rails new runs webpacker:install by default. Because of such a state, I think that we should not recommend to use spring-watcher-listen.

Spring has polling watcher, restart process works without this
spring-watcher-listen. Because of polling base, CPU load may be higher than listen base. Still I think that it is better than the warning comes out.

[schneems]

Looks good to me, who added it? Can we bring them in on the discussion?

[y-yagi]

Can we bring them in on the discussion?

Good point. Thanks.

@fxn You added spring-watcher-listen by 00a5eb6. How do you think about this PR?

[fxn]

Hey, quick heads up.

Reason was performance in large projects, where walking the project tree constantly may not be cheap. Think Shopify.

Same reason Rails introduced reloading based on listen, to be reactive and avoid polling.

[fxn]

In principle, as a first thought, I think I'd open an issue in the gem to discuss it. listen is able to ignore patterns, so we could see if the gem can be more smart about what to watch in Rails 6 apps.

WDTY?

[y-yagi]

Unfortunately, Listen's ignore option does not really ignore directories. The directories are still watched by the native adapter, and events are only filtered after they are fired. Therefore, properly specifying the ignore option does not solve this issue.
Ref: https://github.com/guard/listen/wiki/Duplicate-directory-errors#how-to-correctly-prevent-the-error-in-your-project, guard/listen#274, guard/listen#338

[y-yagi]

Reason was performance in large projects, where walking the project tree constantly may not be cheap.

Thanks for your description. In my understanding, the role of spring watcher is to watch only files that want to monitor for a restart of spring. As this is only a part of the files such as initializers and database.yml, I think that it will not be an issue unless it is really large.

[jordan-brough]

@y-yagi removing spring-watcher-listen only partially resolves the problem for me.

Removing spring-watcher-listen does eliminate the warnings when starting a rails console (spring stop && rails console) in my example app.

However, see this branch of my example app where spring-watcher-listen is removed but I still see warnings when I invoke reload! within a Rails console:

Show repro

$ spring stop && rails console
Spring stopped.
Running via Spring preloader in process 30245
Loading development environment (Rails 6.0.0.rc1)
001 > reload!
Reloading...
=> true
002 >         ** ERROR: directory is already being watched! **

        Directory: /Users/jordan/repos/example-already-watched/node_modules/.bin/compression-webpack-plugin

        is already being watched through: /Users/jordan/repos/example-already-watched/node_modules/compression-webpack-plugin

        MORE INFO: https://github.com/guard/listen/wiki/Duplicate-directory-errors
        ** ERROR: directory is already being watched! **

        Directory: /Users/jordan/repos/example-already-watched/node_modules/@rails/webpacker/node_modules/.bin/compression-webpack-plugin

        is already being watched through: /Users/jordan/repos/example-already-watched/node_modules/compression-webpack-plugin

        MORE INFO: https://github.com/guard/listen/wiki/Duplicate-directory-errors

[fxn]

Hey, need to work on a presentation for tomorrow, I'll eventually come back to this issue.

[y-yagi]

@jordan-brough Thanks for your report.
That is another issue. That issue is that CacheExpiry uses a watcher without specifying a target when reload!. I will investigate.

rails/actionview/lib/action_view/cache_expiry.rb

Line 27 in c926ca4

@watcher = @watcher_class.new([], watched_dirs) do

[matthewd]

I don't know much about spring-watcher-listen, but could we teach it that it's dangerous to listen at the root, and that it should instead install listeners on interesting subdirectories, and then use polling for the remaining top-level files?

[y-yagi]

it should instead install listeners on interesting subdirectories, and then use polling for the remaining top-level files?

I tried to implement this, maybe can do. y-yagi/spring-watcher-listen@c3c697d
However, since the top-level file is monitored by default, the polling thread is executed by default, so I think that CPU load may still increase.
(Of course if don't watch top-level files, I think there are benefits)

[rafaelfranca]

If this by default will increase CPU why should not we remove it? I think the benefits that it may bring doesn't overweight the problems that it will cause.

[rails-bot]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.

[ngan]

@y-yagi is there a reason to keep the listen gem in the default Gemfile if we’re taking out spring-watcher-listen?

[rafaelfranca]

Yes. It is for the evented file updater.