Docs contribution idea: Alternative way of placing the Service Worker file with webpack

[Miguel Silva]

First of all, thank you @kettanaito and rest of the contributors for the msw library and this amazing documentation 👏

Motivation

In some of my projects I have a dev environment that relies on webpack-dev-server, that happens to not have a predefined "public" directory.

The easiest way I found to make it work for me was to use CopyWebpackPlugin to get the Mock Service Worker file into the served content, as follows:

// webpack.config.js
const { SERVICE_WORKER_BUILD_PATH } = require('msw/config/constants');
const CopyPlugin = require('copy-webpack-plugin');

module.exports = {
  ...
  plugins: [
    new CopyPlugin({
      patterns: [{ from: SERVICE_WORKER_BUILD_PATH }],
    }),
  ],
  ...
}

A nice bi-product of doing it this way is that the Mock Service Worker file is always up to date throughout eventual msw version bumps.

Since I found this useful for me, I was thinking about adding this to the documentation as an alternative way to the init method.

How can I contribute?

First I'd like to know if you think that this is a proper way of bringing in the Mock Service Worker file, and also whether it makes sense to mention it in some way in the official docs.

In case it makes sense, I was thinking about where it should be placed. IMO, it could probably live on its own as a Recipe and as secondary/alternative way to Setup.

Let me know what you think!

[Artem Zakharchenko]

Hey, @miguel-silva! Thank you for the feedback.

The main reason we recommend copying the worker script using our CLI is because sometimes you don't have access to webpack configuration, or don't have a sufficient knowledge to safely adjust one. We do mention the alternative browser setup with webpack, yet it doesn't cover copying the worker script.

Copying the script is also build tool-agnostic, as opposed to various copying plugins that are bound to the internal hooks of tools like webpack or rollup.

A nice bi-product of doing it this way is that the Mock Service Worker file is always up to date throughout eventual msw version bumps.

I definitely like the automatic sync with the worker script updates. I admit accessing SERVICE_WORKER_BUILD_PATH is rather clever, I didn't expect people would utilize those internal constants. At the same time those constants are not the public API, so they can get renamed/removed at any point without being a breaking change. However, if you do rely on them in your webpack setup, it becomes a breaking change for you. I'm against documenting internal changes of this sort in changelogs, as it brings unnecessary details and clutter. That is the reason why I think it's not a reliable thing to recommend in the docs.

We can make that constant a part of a public API, but I'm not sure whether that's a good idea. You can definitely rely on it the way you do, and it does have some benefits, yet conceptually it's not something you would normally use when working with the library.

A compromise here would be a custom webpack plugin that would abstract the usage of such internal constants and reflect their changes internally. Such plugin may register the worker directly from the node_modules, because you can utilize the Service-Worker-Allowed header on the WDS to skip the worker script location check. That means the copying wouldn't be necessary.

I do believe this is a clever setup, but I'm uncertain where and how to recommend this.

[Miguel Silva]

I definitely like the automatic sync with the worker script updates. I admit accessing SERVICE_WORKER_BUILD_PATH is rather clever, I didn't expect people would utilize those internal constants. At the same time those constants are not the public API, so they can get renamed/removed at any point without being a breaking change.

Fair point. I also felt that it was a bit flaky to rely on an internal constant and that was part of what led me to this issue: together with people more comfortable with the ins-and-outs of the library, solidify an approach (similar or not to this one) that doesn't rely on a init step.

A compromise here would be a custom webpack plugin that would abstract the usage of such internal constants and reflect their changes internally. Such plugin may register the worker directly from the node_modules, because you can utilize the Service-Worker-Allowed header on the WDS to skip the worker script location check. That means the copying wouldn't be necessary.

I like the idea! Nevertheless, wouldn't it still need the worker location to be part of the public API, in order to register the worker directly from the node_modules?

[Artem Zakharchenko]

I like the idea! Nevertheless, wouldn't it still need the worker location to be part of the public API

Not necessarily. From hard-coding the worker script's location, to accessing it directly from the /constants/ like you did (that is not public) would work. I'm more concerned about the maintenance of such loaders, it feels like a lot of effort for a little output.

At this point I can recommend to implement that loader yourself, if you feel the need. I think we will revisit the integration part in the future, but I don't have this in the nearest scope.