Teach the generator to read Rails 8 params.expect

[VSN2015]

The gap

permittable:generate is the adoption on-ramp — and it was blind to the syntax Rails 8 apps actually use. A modern controller has no params.permit calls to scan, so the draft silently fell back to columns alone and lost everything the app already knew about its own params: the root:, the permitted key list, and which keys aren't columns at all.

docs/comparison.md positions squarely against params.expect, so being unable to read one was a conspicuous hole.

The fix

params.expect(user: [:name, tag_names: [], address: [:city, :zip], line_items: [[:sku, :quantity]]])

is now scanned into the same Scan, merged with any permit calls in the same controller. The parser stays exactly as conservative as the permit one — brackets and newlines are fine, a parenthesis means a method call in the arguments and the whole call is skipped rather than half-read.

Two things expect says that permit could not

This is where the draft gets better than a permit-derived one rather than merely equivalent.

1. An array of hashes is unambiguous. permit's key: [:a] could be a nested hash or an array of hashes, which is why that draft has always carried a TODO. expect spells them differently:

Source	Draft
address: [:city]	optional :address do ... end (+ TODO: may be an array of hashes)
line_items: [[:sku]]	array :line_items do ... end — no TODO

Scan carries a new nested_arrays member alongside nested.

2. A route param is not a field. In params.expect(:id, user: [:name]) the :id is a routing key, not body input. Drafting it as a contract field would be wrong, so it stays visible in a TODO instead:

scan = Permittable::Generator.scan("params.expect(:id, user: [:name])")
scan.root      # => :user
scan.scalars   # => [:name]
scan.unparsed  # => [":id"]

So does a second envelope (params.expect(user: [...], address: [...])), which belongs under a different root: than one rooted contract can express — the recipe there is a rootless contract with a nested block per key, which the generator can't decide for you.

A rootless params.expect(:q, :page) still drafts as scalars, since there's no envelope for those to be a sibling of. And tag_names: [] isn't mistaken for an envelope.

Verification

• 210 examples, 0 failures (12 new, written before the implementation), including a draft that is class_eval'd into a real contract and validates a nested + array-of-hashes request
• RuboCop clean
• One bug caught by the specs and worth noting: single-capture String#scan yields a one-element Array rather than auto-splatting the way the two-group PERMIT_CALL does

[VSN2015]

Review of PR #17: Support for Rails 8 params.expect in Permittable::Generator modernizes contract drafting for Rails 8+ codebases.

[VSN2015]

NESTED_ARRAY_ARG pattern cleanly disambiguates Rails 8's comments: [[:body, :author]] syntax from regular nested hashes, allowing accurate generation of array :comments do ... end.

[VSN2015]

Keeping route arguments (like :id alongside user: [...]) in result.unparsed with clear # TODO comments ensures developers are aware of route params without generating invalid body field definitions.