You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some modules in the codebase that are designed to be standalone, depending only on PHP core classes. A typical example is our Clock module.
Currently, we express this constraint like this:
// The Clock module should be standalone.// It can only use PHP core classes like DateTime.
Rule::allClasses()
->that(newResideInOneOfTheseNamespaces('Acme\Clock'))
->should(newNotHaveDependencyOutsideNamespace(
'Acme\Clock',
externalDependenciesToExclude: ['DateTimeImmutable', 'DateTime']
))
->because('the Clock module must be almost standalone');
We’ve found this expression a bit verbose and hard to generalize. To make the intent more clear and easier to read, I’d like to propose supporting a more concise alternative:
This alternative would improve the readability of the rule, especially when applied to multiple modules with similar constraints (e.g., pure helpers, adapters, or low-level libraries).
Thanks!
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Feature Request
Summary
We have some modules in the codebase that are designed to be standalone, depending only on PHP core classes. A typical example is our Clock module.
Currently, we express this constraint like this:
We’ve found this expression a bit verbose and hard to generalize. To make the intent more clear and easier to read, I’d like to propose supporting a more concise alternative:
This alternative would improve the readability of the rule, especially when applied to multiple modules with similar constraints (e.g., pure helpers, adapters, or low-level libraries).
Thanks!
The text was updated successfully, but these errors were encountered: