feat(expo): Dynamically resolve default integrations based on platform

[krystofwoldrich]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Currently, the same default integrations are added for all types of builds. This causes multiple warnings and error logs during event processing. Although events are processed correctly this might confuse the SDK users.

Before:

After:

Note: The SDK Info warning will be removed in the next PR with Expo Modules implementation.

💚 How did you test it?

sample app

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled
• All tests passing
• No breaking changes

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against ecde2d0

[github-actions]

Android (legacy) Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	380.16 ms	399.86 ms	19.70 ms
Size	17.73 MiB	19.84 MiB	2.11 MiB

Baseline results on branch: expo

Startup times

Revision	Plain	With Sentry	Diff
bc4097b	419.25 ms	458.81 ms	39.56 ms

App size

Revision	Plain	With Sentry	Diff
bc4097b	17.73 MiB	19.84 MiB	2.11 MiB

[github-actions]

Android (new) Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	368.31 ms	390.04 ms	21.73 ms
Size	7.15 MiB	8.11 MiB	989.12 KiB

Baseline results on branch: expo

Startup times

Revision	Plain	With Sentry	Diff
bc4097b+dirty	378.29 ms	413.31 ms	35.01 ms

App size

Revision	Plain	With Sentry	Diff
bc4097b+dirty	7.15 MiB	8.11 MiB	988.88 KiB

[github-actions]

iOS (new) Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1212.35 ms	1216.16 ms	3.81 ms
Size	2.92 MiB	3.43 MiB	528.70 KiB

Baseline results on branch: expo

Startup times

Revision	Plain	With Sentry	Diff
bc4097b+dirty	1229.02 ms	1235.65 ms	6.63 ms

App size

Revision	Plain	With Sentry	Diff
bc4097b+dirty	2.92 MiB	3.43 MiB	528.75 KiB

[lucas-zimerman]

The comments that I made also applies to the old behaviour so it's not blocking this PR, with that I am approving the PR :D

[lucas-zimerman]

users can set this parameter to true, should we also check for notweb() here?

[krystofwoldrich]

I thought about that too, probably isNativeAvailable would be even better, since there can be the case when we are not on the web but native is not available.

But since the enableNative was in the past enforcing I wanted to keep that.

[lucas-zimerman]

should we warn users if debug is enabled that attachScreenshot will not be enabled because it's not supported on the web environment?

[krystofwoldrich]

I see the point, I think it makes sense, but for now, I would leave the warning only for cases when we expected something to work and it doesn't. So in happy scenarios, there are no warnings.