moleculer-web v0.10 middleware signature change drops custom response headers on static assets

Answer

In moleculer‑web v0.10 set response headers on static assets by using the new (ctx, next) signature and registering your middleware before the built‑in static handler (which now runs after the error handler).

How to set headers

// header‑setting middleware (v0.10 signature)
async function setStaticHeaders(ctx, next) {
  // request‑phase: add headers that should be sent with the response
  ctx.res.setHeader('Cache-Control', 'public, max-age=3600');
  ctx.res.setHeader('Access-Control-Allow-Origin', '*');
  await next(); // let the static handler (or other middleware) run
}

Register it before the static service:

// moleculer service schema
module.exports = {
  name: 'gateway',
  mixins: [Web],
  settings: {
    port: process.env.PORT || 3000,
    routes: [
      {
        path: '/',
        // your header middleware comes first
        use: [setStaticHeaders],
        // then the static asset handler
        assets: { folder: 'public', etag: true } // enable ETag if needed
      }
    ]
  }
};

Likely explanation

• The middleware signature changed from (req, res, next) to (ctx, next) where ctx.req and ctx.res expose the original objects.
• In v0.10 the built‑in error handler runs before the static file handler (ordering reversed vs. v0.9). Therefore any middleware that should affect static responses must be placed before the static handler (and after any error handler you want to skip for static files).
• ETag generation is disabled by default (etag: false). Setting etag: true restores the v0.9 behavior of emitting ETag headers; no other caching defaults (e.g., Last‑Modified) changed.

Confirmed facts (based on release notes)

1. Middleware signature: (ctx, next) with ctx.res for header manipulation.
2. Static handler ordering: runs after the error handler.
3. ETag default: false in v0.10; true reproduces v0.9 ETag emission.

Migration path for staged rollout

To keep header behavior identical across v0.9 and v0.10 during a gradual upgrade, wrap your existing v0.9‑style middleware in an adapter that translates the signature:

function adaptV09Middleware(oldMiddleware) {
  return async function(ctx, next) {
    // call the original middleware with (req, res, next)
    return oldMiddleware(ctx.req, ctx.res, next);
  };
}

// usage
const adapted = adaptV09Middleware(myV09HeaderMiddleware);
// register `adapted` before the static handler as shown above

This preserves the exact header‑setting logic while allowing you to test the v0.10 gateway alongside the v0.9 version.

Missing diagnostic detail

If you have replaced or disabled the built‑in error handler, the ordering reversal may not apply. Confirm whether you are using the default error handler or a custom one; this determines if the middleware must be placed before or after the static handler for static‑asset responses.