Add auto-discovery of popular PHP frameworks

[vladanpaunovic]

Problem Statement

I would like to know which PHP frameworks are people using with our sentry/sdk so we can make a better informed decisions on which frameworks to support more and when.

We already have a modules integration which is opt in and very few people know about it, hence few of them are actually using it. So the information we get from there are not sufficient enough to drive any meaningful decisions.

Solution Brainstorm

1. create a list of top 10 php frameworks
2. on sentry.init() check whether users framework is in one of top 10
   • ideally, we should find alternative/better methods to discover a framework and fallback to composer.json as a last resort in order to minimise the impact on customers overhead.
3. utilise the same modules object on event payload to store the framework like:

'modules' => [
  'some/framework' => '1.2.3', // if version is unknown to us, use unknown
  ...
]

[Jean85]

Note: since Composer 2 (or since we use jean85/pretty-package-versions anyway), accessing composer.json info has low to no overhead, since we can retrieve information on installed packages from the Composer API, which stores everything in a dumped array.

[cleptric]

Slightly OT, but why do we not support Composer 1?

[Jean85]

@cleptric what do you mean? We do... Do you have issues using it?

[stayallive]

We can probably enable the ModulesIntegration integration by default if we are okay with that by the way, looks like other SDKs also enable this by default anyway.

We just mustn't fail if the info is not available like now happens if we can't find our own version for example, just fallback to sending nothing, quietly.

I'm not sure if we need to hardcode framework packages since then we would be sending all package versions anyway and we can filter out the ones we want server side?

[cleptric]

@Jean85 We had a customer reach out and report similar issues as in #1008. So you updated your package to work with Composer v1/v2 out of the box?

@stayallive We also discussed that option. I have no strong opinion on this, but I see the benefit it would provide us (Sentry) to choose our focus points in the PHP landscape. If there are no strong opinions against making it a default integration, I'm happy to proceed with this.

[Jean85]

@Jean85 We had a customer reach out and report similar issues as in https://github.com/getsentry/sentry-php/pull/1008. So you updated your package to work with Composer v1/v2 out of the box?

We support both: https://github.com/getsentry/sentry-php/blob/master/composer.json#L28

See https://github.com/jean85/pretty-package-versions#compatibility If you used Composer v2 at any point to update packages, it upgraded that package to v2. If you go back to Composer v1, you need to downgrade it to 1.5; I normally see this issue when there's poor dev environment hygiene, and so Composer updates go wrong.

[vladanpaunovic]

Great convo folks! Thank you all! I am happy that I am not the only one passionate about this! 😄

Given that @Jean85 provided us pretty-package-versions, @cleptric we could simply measure the overhead of ModulesIntegration just to play it safe and if it is really low, I say we enable it by default to unify it with other SDKs.

[Jean85]

@cleptric we could simply measure the overhead of ModulesIntegration just to play it safe and if it is really low, I say we enable it by default to unify it with other SDKs.

Keep in mind to test it against Composer v1 AND v2, the inner workings are widely different.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀