ImplicitIncludeArguments
ImplicitIncludeArguments
Severity: warning | Type: LiquidHtml
This check reports a variable an {% include %}'d partial reads that the call site does not pass.
Unlike {% render %}, which runs a partial in a fresh scope, {% include %} runs it in the caller's scope. A variable the partial reads and the call does not pass is therefore not missing — it resolves from the caller, and the page works. That is why this is a warning about explicitness rather than an error: nothing is broken, but a reader of the call site cannot see what the partial needs, and nothing warns you when the caller later stops defining it.
This check only runs when the included partial has NO {% doc %} tag. A {% doc %} tag is a declared contract, and MissingRenderPartialArguments enforces it at an {% include %} site as an error, exactly as it does at a {% render %} site. Only the inferred case is a warning, because inference cannot tell a partial that deliberately shares its caller's scope from one that simply wanted an argument.
The same shape at a {% render %} site is an error from PartialCallArguments: there the variable really is undefined inside the partial, and the output is always empty.
Objects the platform supplies are reported too. content_for_layout in a layout, or forloop inside the {% for %} loop the include sits in, are exactly the inherited-scope reliance this check exists to surface — and each one can be passed explicitly.
Examples
✗ Incorrect Code Example (Avoid using this):
{% comment %}app/views/partials/order/row.liquid{% endcomment %}
<td>{{ forloop.index }}</td>
<td>{{ order.name }}</td>
{% comment %}Calling site — 'forloop' works, but only by inheritance{% endcomment %}
{% for order in orders %}
{% include 'order/row', order: order %}
{% endfor %}
✓ Correct Code Example (Use this instead):
{% for order in orders %}
{% include 'order/row', order: order, forloop: forloop %}
{% endfor %}
The suggested fix passes the variable under its own name, which hands the partial the value it was already reading from the caller — the behavior does not change, only what the call site says about itself.
If the partial does not actually need the caller's scope, {% render %} is the better tag: it makes the parameter list the only way in, so the same omission becomes an error instead of a warning.
Configuration
The default configuration for this check:
ImplicitIncludeArguments:
enabled: true
severity: warning
Disabling This Check
Disable this check if your codebase uses {% include %} for scope sharing deliberately — helpers that read and write the caller's variables, or partials included from a layout that rely on what the layout defines. Disabling it does not affect the real errors: PartialCallArguments keeps reporting missing arguments at {% render %} and {% function %} sites, keeps reporting arguments the partial never reads at an {% include %} site, and MissingRenderPartialArguments keeps enforcing declared contracts everywhere.