fix(interop): Move BlockInterface, InlineInterface, and VoidInterface to ui-awesome/html-contracts and remove interface implementation from all enums in this package.#12
Conversation
…rface` to `ui-awesome/html-contracts` and remove interface implementation from all enums in this package.
📝 WalkthroughSummary by CodeRabbit
WalkthroughRemoves three marker interfaces (BlockInterface, InlineInterface, VoidInterface) and updates enums to be plain string-backed enums without implementing those interfaces; adds a CodeRabbit configuration file and related CI/docs adjustments to reflect the API change. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Block.php`:
- Line 8: Update the doc comment for the Block enum to avoid implying HTML
content-model taxonomy; change the description to a neutral phrasing that
reflects the library's classification based on the begin()/end() API rather than
HTML "block-level" semantics—refer to the Block enum (backed string enum) and
its use with the begin()/end() API so the comment indicates these are tags
grouped by the library's API behavior, not the HTML content-model.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
docs/svgs/features-mobile.svgis excluded by!**/*.svgdocs/svgs/features.svgis excluded by!**/*.svg
📒 Files selected for processing (18)
.coderabbit.yaml.gitattributes.gitignoreCHANGELOG.mdREADME.mdUPGRADE.mdcomposer.jsonsrc/Block.phpsrc/BlockInterface.phpsrc/Inline.phpsrc/InlineInterface.phpsrc/Lists.phpsrc/MetadataBlock.phpsrc/MetadataVoid.phpsrc/Root.phpsrc/Table.phpsrc/VoidInterface.phpsrc/Voids.php
💤 Files with no reviewable changes (3)
- src/InlineInterface.php
- src/BlockInterface.php
- src/VoidInterface.php
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: composer-require-checker / PHP 8.5-ubuntu-latest
- GitHub Check: linter / Super Linter
- GitHub Check: linter / Super Linter
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: terabytesoftw
Repo: ui-awesome/html-interop PR: 11
File: src/Block.php:267-290
Timestamp: 2026-02-21T14:18:01.226Z
Learning: In the ui-awesome/html-interop library, the Block enum classification is based on elements that have begin() and end() methods (separate opening and closing tags), while the Inline enum is for elements rendered on the same line (like <span></span>). This is not based on HTML's standard content categories (block-level vs phrasing content), but rather on the library's API pattern for rendering elements. Elements like <select> and <textarea> belong in Block because they use begin/end methods, even though they are technically phrasing content in HTML specifications.
📚 Learning: 2026-02-21T14:17:54.250Z
Learnt from: terabytesoftw
Repo: ui-awesome/html-interop PR: 11
File: src/Block.php:267-290
Timestamp: 2026-02-21T14:17:54.250Z
Learning: In code reviews for ui-awesome/html-interop, classify Block vs Inline based on the library's API pattern, not HTML's block/phrasing categories. Specifically: - Block enum should include elements that use distinct begin() and end() methods (separate opening and closing tags). - Inline enum covers elements rendered on the same line. Do not rely on HTML content-model assumptions. For example, elements like <select> and <textarea> should be categorized as Block because they use begin/end methods, even though they are phrasing content in HTML. Apply this rule consistently to files that define or modify Block/Inline classifications in the codebase.
Applied to files:
src/MetadataVoid.phpsrc/Inline.phpsrc/Lists.phpsrc/Table.phpsrc/Root.phpsrc/Voids.phpsrc/Block.phpsrc/MetadataBlock.php
📚 Learning: 2026-02-21T14:18:01.226Z
Learnt from: terabytesoftw
Repo: ui-awesome/html-interop PR: 11
File: src/Block.php:267-290
Timestamp: 2026-02-21T14:18:01.226Z
Learning: In the ui-awesome/html-interop library, the Block enum classification is based on elements that have begin() and end() methods (separate opening and closing tags), while the Inline enum is for elements rendered on the same line (like <span></span>). This is not based on HTML's standard content categories (block-level vs phrasing content), but rather on the library's API pattern for rendering elements. Elements like <select> and <textarea> belong in Block because they use begin/end methods, even though they are technically phrasing content in HTML specifications.
Applied to files:
UPGRADE.mdcomposer.jsonREADME.md
🔇 Additional comments (17)
composer.json (1)
4-10: LGTM!The description and keywords accurately reflect the package's new focus on string-backed enums after removing the interfaces. The branch-alias
0.4.x-devis consistent with the 0.4.0 version bump..gitattributes (1)
40-43: LGTM!Good addition of the
merge=unionstrategy for CHANGELOG.md to reduce merge conflicts when multiple branches modify the changelog simultaneously..gitignore (1)
31-33: LGTM!Appropriate addition to ignore phpactor configuration files, consistent with other IDE/tool ignores in this file.
CHANGELOG.md (1)
3-5: LGTM!The version bump to 0.4.0 is appropriate for this breaking change, and the changelog entry accurately documents the interface migration and enum changes.
UPGRADE.md (1)
1-9: LGTM!Clear and concise upgrade guide documenting the breaking changes with actionable migration guidance. The three-point structure effectively communicates what was removed, what changed, and how to migrate.
README.md (3)
14-15: LGTM!The tagline and installation version are properly updated to reflect the package's new focus on string-backed enums and the 0.4.0 release.
Also applies to: 28-28
149-176: LGTM!Good update to use
BackedEnumas the type hint instead of the removedBlockInterface. This is the idiomatic PHP 8.1+ approach for accepting any string-backed enum while maintaining type safety.
211-221: LGTM!Clear documentation of the optional contracts package with installation instructions, providing a smooth migration path for users who need interface-based typing.
.coderabbit.yaml (1)
1-222: LGTM!The CodeRabbit configuration is valid and well-structured. Notable settings include:
- Assertive review profile for thorough feedback
- Request changes workflow enabled
- Global learnings scope for cross-repo knowledge sharing
- Comprehensive tool integrations enabled
src/MetadataVoid.php (1)
8-15: LGTM!The
VoidInterfaceimplementation is correctly removed while preserving the enum as a valid string-backed enum. The docblock is appropriately updated to describe the enum's new nature.src/Voids.php (1)
8-15:Voidsmigration is correctly applied.The docblock and
enum Voids: stringdeclaration align with the interface-removal objective without changing enum behavior.src/Lists.php (1)
8-15:Listsenum update looks good.Removing interface conformance while keeping a backed enum is consistent with the new contract direction.
src/Block.php (1)
15-15: Enum declaration change is aligned with the migration plan.Dropping
implements BlockInterfacefromBlockis consistent with the intended BC-breaking contract shift.src/Table.php (1)
8-15:Tableenum transition is clean.The updated docblock and plain backed enum declaration correctly reflect the interface removal.
src/Inline.php (1)
8-15:Inlinedeclaration update is good.The interface removal is applied correctly while preserving enum structure and cases.
src/MetadataBlock.php (1)
8-15:MetadataBlockmigration is correctly implemented.This keeps the enum backed-string behavior intact while removing the old interface dependency.
src/Root.php (1)
8-15:Rootenum change is consistent and safe.The updated declaration and docs align with the package-wide contract migration.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
composer.json (1)
18-18: 🧹 Nitpick | 🔵 TrivialUnused dev dependency:
maglnet/composer-require-checker.The
check-dependenciesscript that used this package was removed (per the commit message), but the dependency remains inrequire-dev. Consider removing it to avoid unnecessary dependency bloat.♻️ Proposed fix
"require-dev": { - "maglnet/composer-require-checker": "^4.1", "php-forge/coding-standard": "^0.1", "phpstan/phpstan": "^2.1", "phpstan/phpstan-strict-rules": "^2.0.3", "phpunit/phpunit": "^10.5" },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@composer.json` at line 18, Remove the unused dev dependency maglnet/composer-require-checker from composer.json's require-dev (the entry "maglnet/composer-require-checker": "^4.1") and update the lockfile by running composer update or run composer remove --dev maglnet/composer-require-checker to remove it and update composer.lock accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@composer.json`:
- Line 18: Remove the unused dev dependency maglnet/composer-require-checker
from composer.json's require-dev (the entry "maglnet/composer-require-checker":
"^4.1") and update the lockfile by running composer update or run composer
remove --dev maglnet/composer-require-checker to remove it and update
composer.lock accordingly.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/dependency-check.ymlcomposer.jsondocs/testing.md
💤 Files with no reviewable changes (2)
- docs/testing.md
- .github/workflows/dependency-check.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: linter / Super Linter
- GitHub Check: linter / Super Linter
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-02-21T14:18:01.226Z
Learnt from: terabytesoftw
Repo: ui-awesome/html-interop PR: 11
File: src/Block.php:267-290
Timestamp: 2026-02-21T14:18:01.226Z
Learning: In the ui-awesome/html-interop library, the Block enum classification is based on elements that have begin() and end() methods (separate opening and closing tags), while the Inline enum is for elements rendered on the same line (like <span></span>). This is not based on HTML's standard content categories (block-level vs phrasing content), but rather on the library's API pattern for rendering elements. Elements like <select> and <textarea> belong in Block because they use begin/end methods, even though they are technically phrasing content in HTML specifications.
Applied to files:
composer.json
🔇 Additional comments (1)
composer.json (1)
4-4: LGTM!The description and keyword updates accurately reflect the package's new focus on enums rather than interfaces.
Also applies to: 10-10
Pull Request