Add matchFilenameOnly start option

[msutkowski]

• Addresses the conversation in Worker registered on different ports in Testcafe #335 by introducing an escape hatch that allows a serviceWorker to be matched on the filename only, disregarding the strict origin/filename match.

[benmonro]

@msutkowski thank you! this looks great to me.

[benmonro]

@kettanaito any thoughts on this? Would really make your testcafe user's experience with testcafe a lot better. 😎

[timdeschryver]

I read the issue and I think this solves that use case (and probably others too).
Another option would be to give the user this responsibility, which would cover all use cases.
It would be more complicated for the user, but it would be more flexible.

I'm not sure it needs to be more flexible tho. Perhaps this is something to keep in mind for when another use case pops up, before adding other options.

e.g.

serviceWorkerFileMatcher?: (scriptUrl:string) => boolean

if (serviceWorkerFileMatcher) {
  return serviceWorkerFileMatcher(worker.scriptURL)
}
return worker.scriptURL === absoluteWorkerUrl

[msutkowski]

Hey, thanks for this idea! I'm a big fan of matcher funcs as well (in this instance, as well as basically any other time it's relevant). I think the only real distinction is that what I'm proposing is the viewpoint: 'as a library, we've thought of what you're going to run into, and this is the easiest way to solve it', and the flag becomes obvious. The matcher func requires slightly more 🧠 power and documentation, but I'd agree that it is probably the better long-term solution.

My only challenge to the matcher func is basically what you said: "not sure it needs to be more flexible". That being said, I'm more than happy to change this to your suggestion and add in the tests once we have a solid decision 🎉.

[kettanaito]

I agree that we should lean towards expanding API outwards (delegating more control to the user), not inwards (encapsulating specific behaviors under flags). Thanks for pointing this out, @timdeschryver!

Depending on when such matcher would be called, we can expose more information about the worker. Ideally, a ServiceWorkerRegistration reference, which contains about all you may need to create a custom registration predicate.

[kettanaito]

Hey, @msutkowski 👋 Sorry for not getting a proper review on this one. Please, is there anything I can help with this pull request? The intention behind it definitely has a place to be, I don't see a custom worker registration predicate as an issue, especially if it helps to solve a problem.

[msutkowski]

@kettanaito Sorry, I should've left a comment when closing. I'll be opening a new PR this afternoon unless you'd prefer the updates done in this branch/PR :)