Ensure --value(…) is required in functional @utility definitions

[RobinMalfait]

While working on #19989, I noticed that --value(…) inside functional @utility definitions is not required right now.

That means that the following CSS is valid:

@utility foo-* {
  color: red;
}

But this doesn't really makes sense, because this now accepts a value and foo-a, foo-b and foo-c would generate the following CSS:

.foo-a {
  color: red;
}
.foo-b {
  color: red;
}
.foo-c {
  color: red;
}

The a, b, and c are not doing anything here apart from making your CSS bigger. So this is very likely an actual bug that you forgot to use --value(…).

Additionally, if a --value(…) was used, but it didn't resolve anything, then we already properly discared the candidate.

Test plan

1. Add test to ensure --value(…) is required in functional @utility definitions
2. Existing tests pass

[coderabbitai]

Walkthrough

This change enforces that functional @utility definitions must include a --value(…) function that successfully resolves. The implementation in the utilities module was updated to reject functional CSS utilities unless both the --value(…) pattern is present and resolves successfully. Test cases were added to verify that utilities without --value(…) produce empty output and that utilities with --value(integer) properly resolve to generate matching classes. A changelog entry was added documenting this requirement.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and specifically describes the main change: requiring --value(…) in functional @utility definitions.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The PR description clearly explains the issue: functional @utility definitions should require --value(...) to prevent unused captured values and unnecessary CSS duplication.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Confidence Score: 5/5

This PR is safe to merge — the logic change is minimal, well-targeted, and covered by new tests.

The one-line condition change correctly covers the previously missed case (!usedValueFn) and the existing case (!resolvedValueFn). No regression risk: the new guard only fires when --value(…) is absent, which previously silently emitted wasteful duplicate CSS. Two focused tests verify both the 'no --value(…) at all' and 'used but unresolved' paths.

No files require special attention.

_{Reviews (1): Last reviewed commit: "update changelog" | Re-trigger Greptile}