[ericproulx]

Fixes #34.

Problem

Within one scope, a route declared above a helpers block couldn't call its helpers:

class API < Grape::API
  resource :foo do
    get(:broke) { hello_helper } # NameError
    helpers { def hello_helper = 'Hello World!' }
    get(:works) { hello_helper } # 'Hello World!'
  end
end

The rule only held for the route's own scope, which made it look arbitrary. On master:

helpers declared…	reaches a route declared before it?
later in the route's own scope	no
later in an enclosing scope	yes
after mount	yes

The cause is that an endpoint is built from a point-in-time copy of its scope's settings (point_in_time_copy_for_endpoint). The copy keeps the scope's own stackables, helpers included, as they were at the route, but its link to the enclosing scopes stays live.

Fix

The endpoint also keeps the live settings of the scope it was declared in, and build_helpers reads the helpers from them in compile!, by which time the whole class body has run. Nothing else reads them. Validations, callbacks, rescue_from and use still come from the copy, so they keep applying only to the routes declared below them.

• A helper declared in a sibling namespace still doesn't reach the route.
• Helpers from enclosing scopes and through mount work as before.

Behaviour change

A helper method defined twice in one scope now answers with its last definition in every route of that scope, including routes declared between the two definitions. It's the usual Ruby rule that the last definition wins. No spec pinned the old behaviour, but it's a contract change, so it gets an UPGRADING entry (4.2.0), with the workarounds: different method names, or separate namespaces. The README no longer lists helpers among the declarations that have to come above the routes they cover.

Warning, until 5.0

The change is silent at runtime, so the endpoint warns about it when it compiles. Its settings copy still holds the helpers the route reached before this PR, so it compares, method by method, the definition the route answered with before against the one it answers with now. It warns only where they differ:

Grape: helper `greeting` is defined again below GET /before in the same scope, so since 4.2.0 that route answers with the later definition (see UPGRADING.md). Rename one of them, or declare the route in its own namespace.

The warning lives in Grape::Endpoint::RedefinedHelpersWarning, so it goes away in 5.0 by deleting one file. That also keeps Endpoint under its Metrics/ClassLength limit, which it went over once rebased onto #3054.

These stay quiet:

• a helper declared below the route that only adds methods (Helpers declared after routes aren't available. #34's case);
• a redefinition in an enclosing scope, which already reached the route;
• the same module declared again.

Private helpers are covered too. The check runs at compile time only, never per request. It goes in 5.0.

params :name helpers used with use are untouched. use resolves them immediately, so they stay order-dependent (#2113, #1761).

Memory

The route endpoint gains a sixth ivar (the comment on build_prototype is updated). Per-request copies hold eight, and measured with ObjectSpace.memsize_of they stay at 80 bytes, with or without helpers.

Tests

Five examples under Grape::API .helpers:

• a helper declared after a route of the same scope reaches it;
• the same inside a namespace;
• a redefinition answers every route of the scope, and warns, once, for the route in between;
• no warning when the helper below only adds methods;
• no warning for a redefinition in an enclosing scope.

Mutation-checked:

• reading the helpers from the copy again fails the first three;
• dropping the warning call fails the redefinition example;
• warning for every method declared below the route fails the "only adds methods" example.

bundle exec rake: 378 files with no offenses, 3189 examples, 0 failures.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run