Modernize test autoloading for a more PHP-native configuration

[Greg0]

Summary

• Align the library with common PHP practices and PSR-4 autoloading.
• Remove legacy patterns carried over from the JavaScript port.
• Simplify and stabilize PHPUnit execution via Composer autoloading.
• Introduce a small, namespaced functional API while keeping classes unchanged.

What’s changed (high level)

• Composer autoloading: rely fully on PSR-4 for the library; expose a minimal functional API via a dedicated functions file registered under "files".
• Removed the legacy “aggregator” entrypoint and manual require chains; consumers can now rely on Composer’s autoloader only.
• Tests now use a proper namespace and Composer autoloading, dropping custom bootstrap and ad-hoc requires.
• PHPUnit configuration and the Composer test script are simplified to use autoloading without a bootstrap file.
• Cleaned up a few trivial tests that only asserted existence of symbols.

Why

• Make the package feel native to PHP rather than a direct JS-style port.
• Reduce global state, manual wiring, and magic class aliases; encourage using real namespaces.

Follow-ups I plan

• Incremental refactors to further embrace PHP idioms.
• Documentation updates to reflect the new usage pattern.
• Optional: static analysis and coding standards to keep the codebase consistent.

This is the first of several PRs aimed at giving the library a more PHP-native feel while preserving existing behavior where possible.

[fahad19]

this is amazing, @Greg0! excellent piece of work.

I was always worried about SDKs in new languages being idiomatic enough or not, and you stepped in at a very crucial moment.

could you kindly merge latest main in your branch, and see if it helps trigger the GitHub Actions workflow for this PR?

if the tests are passing, I will merge and do a new incremental release right after.

many thanks for taking care of this! ❤️

[fahad19]

@Greg0: thanks for updating this PR.

I see that PHP's own tests are passing, but when Featurevisor project's tests are run against the PHP SDK, it's failing here: https://github.com/featurevisor/featurevisor-php/actions/runs/17013976017/job/48234173010?pr=3#step:8:1

to help clarify things a bit more (apologies if you are fully aware of it already):

• Featurevisor has concepts of testing features declaratively: https://featurevisor.com/docs/testing/
• Featurevisor monorepo has several internal example projects, and we are using this example-1 project as a playground for testing various different aspects together: https://github.com/featurevisor/featurevisor/tree/main/examples/example-1
• in featurevisor-php repo, we are setting up the same example-1 project, and running its tests against PHP SDK here in this workflow: https://github.com/featurevisor/featurevisor-php/blob/main/.github/workflows/checks.yml#L40-L48
• The "bin" script is found here: https://github.com/featurevisor/featurevisor-php/blob/main/featurevisor

The expectation is, the test runner should continue to work and pass example-1 project's specs successfully as we continue with this refactoring.

[Greg0]

Thanks for pointing that issues. I will take a look at it soon.

[Greg0]

@fahad19 Please try again to run example-1 tests

[fahad19]

@Greg0: all passing. amazing stuff!

will wait for your green light before merging and releasing.

[Greg0]

Yes, I don't have anything more in that batch of changes. PR #4 will have conflicts, so some adjustments will be needed

[fahad19]

merged, and landed in v0.2.0: https://github.com/featurevisor/featurevisor-php/releases/tag/v0.2.0

welcome to the club of Featurevisor contributors, @Greg0! 🙌

---

regarding versioning, since we are still in v0.x, it's allowed in semantic versioning to still go for some breaking changes until we hit v1.0 stable.