chargebee-php icon indicating copy to clipboard operation
chargebee-php copied to clipboard

Make the lib compatible with PHPStan

Open cybemos opened this issue 11 months ago • 8 comments

What problem does your feature request address?

I use PHPStan to detect errors on static types. No types are currently present in Models.

Usage example

private function logCustomer(Customer $customer): void
    {
        Log::info('logging customer', [
            'id' => $customer->id,
            'country' => $customer->unknownField, // here, PHPStan should be able to know that the field is unknown
        ]);
    }

Describe the desired solution

Here is an example of how to make it compatible with PHPStan.

/**
* @property string $id
* @property string|null $email
* ...
*/
class Customer extends Model
{
    //....
}

Alternatives considered

No response

Additional context

No response

cybemos avatar Jan 23 '25 16:01 cybemos

Hi @cybemos,

Thank you for reaching out! You’ve caught us at the perfect time—we’re actively working on this feature along with many others. Please bear with us as we prepare to roll out a beta version very soon. Here’s a glimpse of how it looks in the new version:


Image 1


Image 2


Image 3


Please feel free to share any other feedback you have on the current SDK.

cb-alish avatar Jan 23 '25 17:01 cb-alish

Chargebee\Resources\Customer instead of ChargeBee\ChargeBee\Model\Customer? that looks like a brand namespace reorganisation then ?

yched avatar Jan 23 '25 17:01 yched

Hi @yched, yes we're also reorganizing the ChargeBee namespace to Chargebee in addition to adding support for type hinting / autocomplete / type definition, injectable HTTP client etc.

I'd love to hear if you have any feedback on anything that we can improve in the SDK.

cb-sriramthiagarajan avatar Jan 24 '25 13:01 cb-sriramthiagarajan

@cb-sriramthiagarajan injectable HTTP client is awesome news ! (as is type hinting & autocompletion, of course) Any ETA ? :-D

any feedback on anything that we can improve in the SDK

I would say, the ability to use different HTTP clients (with different timeout configuration) for POST requests and GET requests, would be very handy. GET requests typically takes a few 10ms/100ms, but POST requests can take much longer (notably requests that trigger gateway payments). So with one single timeout config for both, we are forced to set a very high value (like 20 or 30 secs). But ideally, we would like use much smaller timeouts for GET request ("fail early" : no need to wait 30 seconds to decide there is a network error on a request that should take 300ms at worst)

yched avatar Jan 24 '25 13:01 yched

I would say, the ability to use different HTTP clients (with different timeout configuration) for POST requests and GET requests, would be very handy. GET requests typically takes a few 10ms/100ms, but POST requests can take much longer (notably requests that trigger gateway payments). So with one single timeout config for both, we are forced to set a very high value (like 20 or 30 secs). But ideally, we would like use much smaller timeouts for GET request ("fail early" : no need to wait 30 seconds to decide there is a network error on a request that should take 300ms at worst)

Thanks much for the details @yched. This makes sense. We're planning to have the timeout configurable at the request level.

Any ETA ?

We're targeting to release the first beta version by the end of Feb 2025 and iterate.

cb-sriramthiagarajan avatar Jan 24 '25 15:01 cb-sriramthiagarajan

Now that you got me started, I can think of a couple more things 😅

  • real PHP 8 Enum for values like $subscription->status (active / in_trial / ....), $paymentSource->type (card / direct_debit / ...), etc
  • DTO objects to represent SomeResource::all() input params : Right now if I make a typo in a filter, like Subscription::all(['csutomerId[is]' => 'some_id']), then chargebee silently ignores my filter and returns all existing subscriptions. Since our application adds an extra layer that auto-iterates paginated requests to fetch all results, that could easily get very nasty. Using classed DTO objects with explicit / typed param names, would help a lot preventing such "silently incorrect" requests
  • maybe automatic generation and handling of idempotency keys for POST requests, like Stripe SDK does ? ;-)

yched avatar Jan 24 '25 16:01 yched

Thanks again for sharing these. Yes, we'll be considering these and keep this thread posted.

Keep the suggestions coming :)

cb-sriramthiagarajan avatar Jan 25 '25 06:01 cb-sriramthiagarajan

Hi @yched , @cybemos we're excited to share that we have released the beta version of v4.x. Some of the major changes include:

  • Proper type definitions for requests & responses.
  • Support for injecting HttpClient .
  • Support for modern PHP features like Enums, strict type declarations, updated documentation standards, and modern array syntax.

You can install the beta version with the command below:

composer require chargebee/chargebee-php:@beta

We'd really appreciate if you could play around with this and share your feedback. Check the migration guide for more details.

cb-alish avatar Mar 13 '25 14:03 cb-alish