feat(event-handler-core): give routes a name so one can be decorated

[adrians5j]

Routes get a name, request.route tells a handler which route is running, and route decoration works with a plain DI decorator.

Decorating a route

Decorate HttpRouteHandler. It applies to every route, and request.route.name picks the one you mean:

import { HttpRouteHandler } from "webiny/api";

export default HttpRouteHandler.createDecorator({
  decorator: class implements HttpRouteHandler.Interface {
    constructor(private decoratee: HttpRouteHandler.Interface) {}

    async handle(request: HttpRouteHandler.Request, response: HttpRouteHandler.Response) {
      if (request.route.name !== "my-route-get") {
        return this.decoratee.handle(request, response);
      }

      if (request.headers["x-api-key"] !== "expected") {
        return response.status(401).json({ message: "Not authorized." });
      }

      return this.decoratee.handle(request, response);
    }
  },
  dependencies: []
});

Drop the name check and it wraps every route, which is what you want for timing or logging.

Decorating HttpRouteDefinition is still there for a different job: changing what a route is rather than what it does — point it at a different handler, or move its path.

name and request.route

HttpRouteDefinition gains a name. Framework routes get kebab-case ones (graphql, asset-delivery, cms-manage, background-task). <Api.Route> reuses its existing routeName prop rather than inventing a second naming concept, so a route's DI name and its Pulumi resource name are the same string — deriveRouteName moved into the shared routePath.ts, which is what guarantees they cannot drift.

request.route carries { name, method, path } of the matched definition into handle(), the req.route of Express-style handlers. Note route.path is the PATTERN (/orders/:orderId) while the top-level path is what was requested (/orders/abc123). It is optional on IHttpRequest, because a transport builds a request before anything has matched, and required on HttpRouteHandler.Request, so handlers need no guard.

How the matched route is built

HttpRouter resolves the matched route with container.resolveImplementation(definition.handler), added in @webiny/di 1.1.0 (webiny/di#17). It reads the route's dependencies from its own metadata and applies decorators, which is what makes the plain decorator above work.

Getting there took three wrong turns, all visible in the commit history:

1. resolveWithDependencies + Metadata. It is the only resolve path in @webiny/di that never calls applyDecorators, so routes were silently undecoratable. I documented that as an inherent limitation. It was not.
2. A throwaway child container whose only registration was the matched route, so an ordinary resolve() would find just that one. This worked and restored decoration, but allocated a container per matched route per request and leaned on child-before-parent lookup order rather than a stated contract.
3. resolveImplementation. The actual fix, in the DI package where it belonged.

buildHttpRoute is deleted along the way — it only ever existed to house those workarounds.

Also

event-handler-core peer-depends on @webiny/di@^1.1.0 rather than ^1.0.2, since 1.0.2 satisfies the old range but lacks the method. The other 60 packages move by lockfile.

Two lockfile-level gotchas worth knowing: yarn up does not rewrite peerDependencies, and it leaves transitive ranges alone — @webiny/stdlib's ^1.0.2 kept resolving to 1.0.2 and got a nested copy, which meant two Abstraction classes and a Property '__type' is protected type error. yarn dedupe @webiny/di fixes it.

event-handler-core also gains src/exports/api.ts. The HttpRouteHandler / HttpRouteDefinition exports had been hand-written into the GENERATED packages/webiny/src/api.ts, which generate-webiny-package rightly wipes — the package had no exports folder for the generator to read. With one, validate-webiny-package passes and the package.json export map is correct, which the hand-edit had missed entirely.

Verified

event-handler-core 87, api-headless-cms 920, api-core 181, api-aco 74, event-handler-aws 61, api-graphql 42, project-aws 31, plus the smaller suites. Full uncached build clean. adio, format:check, oxlint, sync-dependencies, validate-webiny-package all clean.

The tests that matter most are the ones pinning behaviour that is easy to lose: an unmatched route is never built, a matched route's dependencies are, and decorators reach the matched route. Those survived all three implementations above unchanged, which is how each rewrite was checked.

[github-actions]

🚓 Slop Cop

✅ Nothing worth flagging. The diff looks consistent with the PR's stated intent and the code-style rules.

The PR matches its stated intent — a broad but coherent, mechanical change (adding name to HttpRouteDefinition everywhere it's implemented, plus a version bump for @webiny/di that touches every package.json/yarn.lock) — with no integrity or style issues found.

_{Automated, non-blocking heads-up from an LLM. It can be wrong — use your judgment. Regenerates on every push.}