Skip to content

Add version-specific rulesets for OpenEMR compatibility #4

@kojiromike

Description

@kojiromike

Feature Request

Add version-specific ruleset files to allow module developers to enforce rules based on their minimum supported OpenEMR version.

Motivation

Module developers may need to support multiple OpenEMR versions. Some rules enforce patterns that only work with newer OpenEMR features:

  • QueryUtils and OEGlobalsBag may not be available in older versions
  • Symfony Request/Response patterns may be added in later versions
  • Modules targeting older OpenEMR versions shouldn't be forced to use unavailable APIs

Proposed Solution

Create version-specific ruleset files:

openemr-7.0.2.neon    # Rules for modules targeting OpenEMR >= 7.0.2
openemr-7.0.3.neon    # Rules for modules targeting OpenEMR >= 7.0.3
openemr-7.1.0.neon    # Rules for modules targeting OpenEMR >= 7.1.0

Each file would:

  • Include rules appropriate for features available in that version
  • Use includes: to inherit rules from previous versions
  • Be clearly documented in README

Example Usage

For a module supporting OpenEMR 7.0.3+:

# phpstan.neon
includes:
    - vendor/openemr/phpstan-openemr-rules/openemr-7.0.3.neon

Benefits

  1. Progressive adoption: Module developers can adopt stricter rules as they drop support for older versions
  2. Clear compatibility: File names make version targeting explicit
  3. Backward compatibility: Existing core.neon and module.neon remain unchanged
  4. Flexibility: Developers can still cherry-pick individual rules if needed

Implementation Notes

Need to determine:

  • Which OpenEMR version introduced each enforced pattern (QueryUtils, OEGlobalsBag, Symfony patterns)
  • Appropriate versioning strategy (match OpenEMR releases or use semantic versioning)
  • Documentation updates for README and migration guide

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions