Service mode

[aomarks]

By default, Wireit assumes that scripts eventually exit by themselves. This works well for things like building or testing. But sometimes a script runs indefinitely, such as a server.

Setting "server": true will tell Wireit that a script runs indefinitely. This has the following effects:

• It will always run. It will never be skipped or restored from cache.

• If something depends on the server, Wireit won't wait for the server to exit before the dependent script starts running. Instead, it just waits for the server process to be spawned.

• If a server script is run directly (e.g. npm run serve), then it will stay running until the user kills Wireit (e.g. Ctrl-C).

• If a server script is run indirectly (e.g. npm run script-that-depends-on-server), then the server script will stay running until all scripts which transitively depend on it have finished.

• In watch mode, Wireit will restart the server whenever a dependency changes. If this isn't required for a particular dependency (such as for static assets that the server does not cache), the dependency edge can be annotated with "restart": false.

{
  "scripts": {
    "build": "wireit"
  },
  "wireit": {
    "serve": {
      "command": "node lib/server.js",
      "server": true,
      "dependencies": [
        "build:server",
        {
          "script": "build:assets",
          "restart": false
        }
      ],
      "files": [],
      "output": []
    }
  }
}

[justinfagnani]

I hit this today: I somewhat naively configured a server script as a dependency of another server script (Firestore emulator as a dependency of a file server, file server as a dependency of app server, etc).

I did not get an error though - I just saw no progress on the wireit output. The script I ran was depending on a build step and a server and the output just stopped after the build completed. I thought the build might have hung.

In this case there aren't strict requirements that one server finish starting before another starts, so I can just make them all sibling dependencies of a step that won't complete. I've had previous project where I might have needed to wait for some specific output from the server before considering it started though.

[justinfagnani]

What's your thought for how to do this? Something like a "daemon": true flag?

I could imagine that and maybe a "readyMatch" field that takes a regex string to look for in stdout to indicate a server is ready to count the dependency as complete.

[justinfagnani]

I did eventually run into a spot where I needed to start a server to run an integration test...

[ZachHaber]

In addition to a server as a dependency, wireit should also expect a server as the end result of a command in general.

I was trying to set up wireit to work for running a server in watch mode for development, and the issue I ran into is that the watch mode doesn't start watching again until after the server is shut down, which doesn't work well for a dev environment.

For reference:

I've tried several different approaches at this point to this problem with varying degrees of success.

nodemon is probably the best overall still despite being slow. tsc-watch is faster, but fails to properly shut the server down if you save it twice in quick succession which then requires manual intervention. tsc's watch mode has no way to run a command after it, which makes it impossible to use.

I also really love the if-file-deleted feature as that solves a huge issue I've been frustrated with.

Package.json

{
  "scripts": {
    "start:dev": "env-cmd -e dev node dist",
    "local:dev": "env-cmd --no-override -e dev,local npm run start",
    "local:prod": "env-cmd --nor-override -e prod,local npm run start",
    "start": "wireit",
    "ts": "wireit"
  },
  "wireit": {
    "start": {
      "command": "node dist",
      "files": [
        "dist/**/*.js"
      ],
      "dependencies": [
        "ts"
      ]
    },
    "ts": {
      "command": "tsc --build --pretty",
      "clean": "if-file-deleted",
      "files": [
        "src/**/*.ts",
        "tsconfig.json"
      ],
      "output": [
        "dist/**",
        ".tsbuildinfo"
      ]
    }
  },
}

[aomarks]

I was trying to set up wireit to work for running a server in watch mode for development, and the issue I ran into is that the watch mode doesn't start watching again until after the server is shut down, which doesn't work well for a dev environment.

Yeah, this is a high priority issue.

In your case, would restarting your server on each watch iteration work?

I was also thinking that you often have some dependencies which require a restart, and some which don't. So maybe you declare like this:

"wireit": {
  "my-server": {
    "command": "node my-server.js",
    "server": true,
    "dependencies": [
      {
        "name": "build:server-implementation",
        "restart-on-change": true
      },
      {
        "name": "build:assets",
        "restart-on-change": false
      }
    ]
  }
}

I also really love the if-file-deleted feature as that solves a huge issue I've been frustrated with.

🙂

[ZachHaber]

I feel like restart-on-change would be problematic and redundant with "files".

I.e. "files": [] would indicate that it shouldn't ever restart. "files": ["*"] would presumably indicate that it'd restart when anything changes.

Then the logic would work with whatever "server" settings we have to indicate it's a continuous process (I'm not sure the best term). I.e. "files": [] in the build:assets command would function by telling it to just re-use whatever output. However if build:assets was a continuous process, then it would just keep it running until its files changed, and an empty array would signify that it will never change.

And of course, if there's dependencies for a continuous process, it'd process them in that order, since the individual dependencies would be specifying their own files and dependencies, and if the files for a longer running process changes, then kill the process and restart it. I suppose that if "files" aren't declared at all, the ideal would to treat it as "if any dependencies indicate they changed" then restart the continuous process.

I could imagine that and maybe a "readyMatch" field that takes a regex string to look for in stdout to indicate a server is ready to count the dependency as complete.

I also think that having some declarative way of signifying when you know that a continuous process is fully started for whatever uses it as a dependency would be nice (in the cases mentioned above where you are chaining multiple continuous processes together).