Use grunt-contrib-watch for server reloading? (or otherwise configurable?)

[tonyarkles]

I admit that I'm abusing lineman a little bit :). Although my server portion isn't that big, it's big enough that it feels a lot better separating it into multiple files. Looking at the code, it looks like the server reloading happens in tasks/server.coffee:

  resetRoutesOnServerConfigChange = (app) ->
    watchr grunt.file.expand('config/server.*'), (err, watcher) ->
      watcher.on 'change', (contexts) ->
        _(contexts).each (context) ->
          userConfig = fileUtils.reloadConfigurationFile("server")

I don't know enough about Grunt to know whether or not it's a good idea or not, but it seems like:

• a separate grunt task could be used to reload and restart the server
• this grunt task could be configured and called from the watch: stanza in application.coffee

As an alternative, it also seems like that glob in the existing code could be replaced by a configurable value instead.

I'm more than happy to do this work myself, I just don't know if it's actually a sane idea :). Possibly the answer is "quit abusing lineman like this, you fool!" but I'm finding that it has so far offered the right balance for prototyping this project out before separating it into a separate express backend for the API portion (if that even needs to happen...)

[searls]

Paging Dr. @jasonkarns, paging Dr. @jasonkarns

[jasonkarns]

To be honest, I'm not terribly familiar with the server portion of Lineman. However, there is a server task which could be triggered by a normal watch stanza.

I presume that watch_r was used instead of grunt watch so that the entire express server needn't be restarted. As it stands, only the routes are reset when the server config changes. However, I have no idea how appreciable the performance difference is between the two approaches.

I think it would be great to start by making the server config glob configurable, as that would be useful even if the server were restarted by grunt watch.

Then I'd like to see the performance impact of making the server config watch use grunt watch instead of watch_r. From there, we could decide if a routes-only restart would be beneficial.