Add also ignore prettier to mockServiceWorker.js

[binarykitchen]

Scope

Improves an existing behavior

Compatibility

• [ ] This is a breaking change

Feature description

Minor suggestion: at the top of the mockServiceWorker.js you have ...

/* eslint-disable */
/* tslint:disable */

(Refer https://github.com/mswjs/msw/blob/main/src/mockServiceWorker.js#L1)

... Which is a great idea. I would also add prettier ignore here. It happens occasionally that this file got changed by prettier in my projects. Thanks

[kettanaito]

Hi, @binarykitchen. Please see the Linting the worker script decision. I think we need to remove the existing pragma comments, not add new ones.

[binarykitchen]

I see @kettanaito - yes, either remove all the existing pragma or stick to the current pattern, not both.

For now, I've added it to .prettierignore, see https://github.com/binarykitchen/videomail-client/blob/master/.prettierignore#L1

Although I don't like that idea either. More hassles for developers. Too many dot files in the project root folders. Why not serve the worker script from a public server?

[kettanaito]

No matter where you serve the worker script from, it's a public asset of your app. You don't lint those. Those live in /public and must be ignored by all your automation tooling.

Why not serve the worker script from a public server?

If you are asking why not serve the script from something like https://mswjs.io/mockServiceWorker.js, then the answer is you cannot by design. Service Workers require you to serve the script from the same origin. Intercepting the network traffic is a sensitive operation, you must make that explicit choice yourself. This is a security consideration coming from the Service Worker spec, and we cannot/shouldn't do anything about it. It's a good consideration.

[binarykitchen]

@kettanaito I see. I don't have a better answer right now. It can be a pain. Alright ...

... for low-risk environments, this can be acceptable, just not on production. Meaning, it adds extra work for us developers to circumvent this.

[kettanaito]

Can you elaborate on what you are trying to circumvent? I'm a bit confused.

It really comes down to you configuring your linting tools correctly. Here's an example:

// .eslintignore
/public

// .prettierignore
/public

You must ignore public assets from linting. That's common sense, not something specific to MSW. Once you do that, the issue is gone.

[binarykitchen]

Good question @kettanaito - it's this public npm package which is on GitHub as well, namely this one: https://github.com/binarykitchen/videomail-client

It does not have a public folder per se, but uses Storybook for testing only. And when I say, testing, I've made a public folder inside the storybook (which feels weird): https://github.com/binarykitchen/videomail-client/tree/master/.storybook

Before I compile and publish new npm versions of this package, all goes into a dist folder, which isn't the same as the public folder. That's my conflict: dist !== public and a public folder on root is only meant for applications, not npm packages or libraries.

Hope you get my point?

[kettanaito]

Sorry, I think I'm missing the point. How is that example relevant? It sounds like you are trying to redistribute MSW's worker in some other package. But even if it is, you must never, ever lint your build artifacts, no matter if they are in dist or build or public.

[binarykitchen]

But even if it is, you must never, ever lint your build artifacts, no matter if they are in dist or build or public.

Of course.

My point is, my above repository does not have any build artefacts at all. It's all very clean. But the pain is, I have yet to declare a path where to put this MSW's worker file somewhere and configure not to lint nor prettify it while that file does not exist at all in the repository.

All good, I'm not too worried about it. It just doesn't feel right, and wonder if you can think of better solutions.