Make the worker updates half-automatic

Current behavior

When the worker registers, the client-side of the library sends a message to it with the latest worker’s checksum to know if your app is running an outdated worker (worker has some changes in the latest version vs. the worker that’s currently running).

Disadvantages

• Worker updates are not apparent. Users find out about them (if they do) only by seeing the console error in a browser.
• Worker updates are manual, as you need to re-run the init command again.

Suggested behavior

The library can check if there’s a designated property set in the project’s package.json that indicates the public directory where the worker script is located (and has been previously instantiated).

// package.json
{
  "msw": {
    "workerDirectory": "./public"
  }
}

Inferring the public directory from other possible settings is a guessing game, as there’s no guarantee that the public directory is otherwise defined or equals to the directory where the user serves the worker script.

When such a relative directory path is provided, MSW will automatically excute the init <WORKER_DIR> command on the postinstall hook of the library. That way any updates (or downgrades) of the msw package are followed by updating the worker script automatically.

If the special property is not specified in package.json, nothing happens. Developer will still see an integrity mismatch error in a browser’s console and would be asked to update the worker script manually (via the CLI).

Advantages

• Worker script updates become automatic.

Disadvantages

• Developer needs to have a special field in package.json to enable this.
• The worker script update becomes implicit, even despite the message printed in stdout.

[kentcdodds]

Yeah, let’s make sure that whatever the solution, when I run the app I can do so without any network connection. This is one of the more compelling use cases for MSW in the first place (and why I sought out a mocking library when I found MSW).

[kettanaito]

Absolutely agree: users must have the capability to develop their apps offline against mocks. We are not stepping down on this experience. After some work on postinstall script and about 20GB of disk space eaten by Yarn, I’ve managed to make it work. I think that’s the first step towards the update automation we’re going to take.