Feedback: Default behaviors

[jitendra-bhandure]

• Open page

Feedback

Feature Request: Introduce In-Place Route Overriding to Prevent Path Hijacking in Large Handler Suites

🚀 The Problem

In large-scale applications with 1,000+ default handlers, routes are carefully pre-sorted so specific static paths come before dynamic wildcards (e.g., /user/messages sits above /user/:id).

However, when using server.use() to mock a specific runtime behavior inside a single test, MSW prepends the new handler to the absolute top of the stack. This causes dynamic overrides to accidentally hijack unrelated static endpoints.

❌ Code Example (The Current Pain Point)

// 1. Global Setup (Sorted correctly out of 1,000+ handlers)
const defaultHandlers = [
  http.get('/user/messages', () => HttpResponse.json({ messages: [] })),
  http.get('/user/:id', () => HttpResponse.json({ id: 'default-user' })),
]

// 2. Inside a specific Test File
test('handles dynamic user fetching', () => {
  server.use(
    http.get('/user/:id', () => HttpResponse.json({ id: 'test-user' }))
  )
  
  // 🚨 CRASH / BUG!
  // If the component under test also triggers a request to `/user/messages`,
  // the runtime override intercepts it because MSW treats "messages" as the `:id`.
  // The test fails because it returns a user object instead of a message array.
})

🧠 Why This Doesn't Scale

To fix this today in a codebase with thousands of routes, developers must either:

1. Write fragile regex constraints (http.get('/user/:id(?!messages|profile|settings|...)')) which break every time a teammate adds a new static route.
2. Manually copy-paste and override every single neighboring route inside that specific test just to maintain the correct evaluation order.

---

💡 Proposed Solution: Introduce server.override()

We propose a native way to inject a handler that respects the existing path specificity, or an explicit method that updates an existing matching route in-place rather than blind prepending.

Option A: In-Place Matching (server.override)

Instead of prepending to the top of the stack, server.override() looks for the existing token pattern match and swaps out only its resolver.

test('handles dynamic user fetching safely', () => {
  // This updates the existing '/user/:id' slot in the handler array 
  // without jumping ahead of '/user/messages'
  server.override(
    http.get('/user/:id', () => HttpResponse.json({ id: 'test-user' }))
  )
})

Option B: Priority/Position Strategy Flag

Allow server.use() to accept an options configuration to control its placement behavior.

server.use(
  http.get('/user/:id', () => HttpResponse.json({ id: 'test-user' })),
  { strategy: 'preserve-order' } // Or strategy: 'append'
)

---

🎯 Benefits

• Scalability: Large enterprise codebases with 1,000+ handlers can write isolated tests without worrying about global route collisions.
• No Maintenance Burden: Developers won't need to update hundreds of tests whenever a new static route is added to the application.
• Predictable Behavior: Mimics how standard backend routers (like Express) allow route overriding without breaking path specificity rules.

[kettanaito]

Hey @jitendra-bhandure. Thanks for sharing your feedback!

There is one crucial thing you are missing (and that I have to talk more about in general) is treating your mocks as your test boundary. Let me elaborate.

Say you want to layer some overrides on top of your default handlers. You've got server.use() for that. You've rightfully pointed out that it prepends handlers, and that's a correct and intended behavior since the whole point of overrides is to, well, _over_ride potentially existing behaviors.

The error in your use case comes from how loose your override is. There's no way for any server to understand that by /user/:id you actually mean a particular user override and not, say /user/messages. No amount of APIs will solve this problem because this is not an API problem to solve.

Solution

The actual solution to this is simple. Scope your override to the context of your test case. Consider this:

const defaultHandlers = [
  http.get('/user/messages', () => HttpResponse.json({ messages: [] })),
  http.get('/user/:id', () => HttpResponse.json({ id: 'default-user' })),
]

test('handles dynamic user fetching', () => {
  server.use(
    // 1. Drop the wildcard. Use an exact user ID for this test case.
    http.get('/user/abc-123', () => HttpResponse.json({ id: 'test-user' }))
  )

  // 2. Later, fetch that same user ID in your tested logic.
  await fetch('http://localhost/user/abc-123')
})

This way, you establish deterministic network behavior layering that doesn't conflict with any of your defined request handlers. In order of priority within this test case:

• /user/abc-123
• /user/messages
• /user/:id

This is one of the most overlooked things about API mocking. Your mocks are your boundary. The goal was never to model your backend behaviors 1-1 in your mocks. The goal has always been to use the mocks to say "given this network behavior, here's how my tested logic must behave".

Always describe the given.

This works great for code bases of any scale and even for any API mocking tools out there. This is how API mocking is meant to be used for the best control over the network. I touch on this briefly in the Server perspective in the docs, but I agree this topic has to be elaborated more on so it's more clear to everyone using the library.