[1.x] Allow retrieving all features for a scope when some features are defined for differing scopes

[cosmastech]

This should resolve #112

We are building a feature flags endpoint for our mobile and web consumers. We need to be able to get all features for 3-4 scopes which are related to the user, but not the user object itself.

I ran into this exact issue earlier today. I saw that this issue had been open for a few weeks without a PR so I figured I'd take a stab at it.

---

Given we have features defined for different scopes

Feature::define('feature-for-user', fn(User $u) => true);
Feature::define('feature-for-team', fn(Team $t) => true);

When we attempt to load all features for a particular scope

$features = Feature::for($user)->all()

Then we expect to receive feature flag definitions ONLY for that apply to Users.

dd($features);
/*
array:1 [
  "feature-for-user" => true
]
*/

Currently, however, an exception is thrown: TypeError: Tests\Feature\DatabaseDriverTest::Tests\Feature{closure}(): Argument #1 ($t) must be of type Workbench\App\Models\Team, Workbench\App\Models\User given, called in /Users/luke/Projects/laravel-pennant/src/Drivers/Decorator.php on line 173

Non-goals of this PR

One outstanding question is: do we expect to allow for union or intersection types in the resolving function? Like Feature::define('team-or-user-feature', fn(Team|User $v) => true); Seems like this probably wouldn't work with how scopes are set up in general. I am sure that my change will not work in this case.

Also, you can still call Feature::for($user)->activate('team-scoped-feature'); I believe that ideally there would be a guard for this, but it seems like it's beyond the scope of this PR.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[taylorotwell]

Drafting pending review from @timacdonald

[timacdonald]

@cosmastech, I have re-worked this one. There were a few problems with the original implementation. The main issue was when a value was resolved for a bad type, it was saved to the database.

The new implementation does the check before attempting to resolve. Supports union and intersection types.

What do you think?

Feature::for($scope)->all() and Feature::for($scope)->loadAll() will now only return or load the features for that scope type.

[cosmastech]

@cosmastech, I have re-worked this one. There were a few problems with the original implementation. The main issue was when a value was resolved for a bad type, it was saved to the database.

The new implementation does the check before attempting to resolve. Supports union and intersection types.

What do you think?

Feature::for($scope)->all() and Feature::for($scope)->loadAll() will now only return or load the features for that scope type.

Thanks for working on this @timacdonald. Sad you removed my given-when-then 😆 but otherwise, nice.

I didn't run any local testing on this, but it seems to solve the problem. Good catch on the DB queries, didn't consider that fact.

[tomirons]

@timacdonald Unfortunately this doesn't work with 3rd party services like LaunchDarkly where the features are defined in their platform.

Any thoughts on adding a check before this to see the namedMap is empty and if it is we load all of the features from $this->defined()?

An alternative could be that I retrieve all of the features from LaunchDarkly within a service provider and define them. But this just seems wrong as I can do the same thing within the defined method on the driver.

[timacdonald]

What are your thoughts on having a contract the drivers can implement to provide a list of features for the given scope?

I suppose the thing we are trying to solve in this PR also impacts 3rd party drivers as well, so feels like we need a way for them to handle things themselves.

[tomirons]

This approach would be perfect!

[timacdonald]

Opened a PR: #127