Allow query parameters in request handlers (resource paths in Sveltekit)

[lubiah]

Scope

Improves an existing behavior

Compatibility

• This is a breaking change

Feature description

Hi,
I noticed that when I include query parameters in handler definitions (like ?/createUser), MSW throws an error and removes them because they are not considered valid resource paths. I understand the intention behind that rule, yet it doesn't apply to certain frameworks.

In SvelteKit, named server actions depend on this exact pattern. A route can define multiple form actions—such as ?/createUser or ?/updateUser—and handle them via separate handlers. It’s common to have many such actions per page, and treating them through query parameters is a core part of how the framework is designed.

Currently, the workaround involves manually parsing the query parameters inside handlers and using conditional logic. That can become tedious and error-prone, especially when you’re juggling multiple actions.

Could you consider adding an option—perhaps suppressQueryParamWarning: true—to allow intentional use of query parameters in handler paths without triggering warnings? This would align better with SvelteKit conventions and help clean up developer experience.

Thank you for considering it!

[kettanaito]

Hi, @lubiah. That's an interesting proposal.

I think it still makes sense to warn and strip off query parameters because most people end up copy-pasting request URLs and end up with obscure handlers. I'd treat your use case as an edge case but still would like to provide a more ergonomic solution that / + manual query handling.

The warning itself isn't the problem. MSW strips off query parameters from request handler paths before request matching. That is something you want changed.

Perhaps the custom predicate could help here (#1804)?

http.post(action('createUser'), resolver)
http.put(action('updateUser'), resolver)

function action(actionName: string) {
  return ({ request }) => {
    const url = new URL(request.url)
    return url.searchParams.get(actionName) != null
  }
}

What do you think? Do you see some limitations with this pattern?

[lubiah]

@kettanaito , thanks for getting back to me.
I don't understand the action function. url.searchParams isn't a function

[lubiah]

The custom request predicate will really help

[kettanaito]

I meant url.searchParams.get in that example. I believe a custom predicate is the best way to solve your issue. We need to make sure that if you're using a custom predicate, the redundant query params warning is skipped altogether since there's no request handler URL to check for those params, to begin with.

We are making some progress on #2541 and I would like to release it sometime next month.

[lubiah]

Thanks @kettanaito . I'd be waiting for this feature

[kettanaito]

You can now do this using a custom predicate function (supported for both HTTP and GraphQL):

function action(actionName: string) {
  return ({ request }) => {
    const url = new URL(request.url)
    return url.searchParams.get(actionName) != null
  }
}

http.post(action('createUser'), resolver)
http.put(action('updateUser'), resolver)

Read more:

• Custom predicate (HTTP)
• Custom predicate (GraphQL)

[lubiah]

Thanks @kettanaito .