Symfony Bundle Laravel Package

Product Decisions This Supports

• Telegram as a delivery channel — build vs buy: This bundle is the Symfony integration layer for Nutgram, a PHP Telegram Bot API framework. It answers the recurring "do we hand-roll a Bot API client or adopt a framework?" question. Adopting it means you inherit Nutgram's routing, middleware, conversation state, and webhook/polling handling instead of maintaining bespoke file_get_contents/Guzzle glue.
• Roadmap timing for framework upgrades: 1.2.0 is a pure compatibility release — PHP 8.4 deprecation cleanup (explicit void return types) plus Symfony 8 support. This is the signal that lets you schedule a PHP 8.4 or Symfony 8 migration without that migration being blocked by your bot integration. Treat it as an enabler, not a feature.
• Feature bets it unlocks: notification/alerting bots (deploy hooks, uptime, order events), internal chat-ops tooling, customer-support and onboarding flows, and lightweight transactional messaging where email is too slow or too noisy.
• Scope boundary decision: Because this is a Symfony bundle, it does not by itself justify a Telegram workstream on a Laravel codebase. It informs the "which integration package do we standardize on per framework" decision rather than a product feature decision.
• Maintenance-risk budgeting: The release shows healthy upkeep (two first-time contributors merged, Symfony 8 tracked promptly) but the project remains a small-maintainer ecosystem. That is an input to "do we accept this dependency for a revenue-adjacent bot, or wrap it behind our own adapter?"

When to Consider This Package

Adopt when:

• The application is Symfony (5.4/6.x/7.x, now 8.x) and you want the bot wired through the container, config, and Flex recipes rather than a hand-rolled service.
• You need real Telegram Bot API surface: commands, handlers, middleware, inline keyboards, conversation state, webhook or long-polling modes.
• You are planning a PHP 8.4 or Symfony 8 upgrade and want the bot layer to be a non-issue — 1.2.0 clears both.
• You want Telegram as one channel inside an existing PHP service so bot logic can reuse your domain services rather than living in a separate runtime.

Look elsewhere when:

• You are on Laravel — this bundle targets Symfony's kernel and DI conventions. Use the Laravel-specific Nutgram integration or a framework-agnostic SDK instead; forcing a Symfony bundle into Laravel is integration debt with no payoff.
• You need multi-channel messaging (WhatsApp, Slack, SMS) behind one abstraction — this is Telegram-only by design.
• You need an SLA-backed vendor, guaranteed release cadence, or long-term commercial support. This is community OSS with a small contributor base; budget for the possibility of pinning a version and carrying patches.
• Your bot is trivial (one webhook, one sendMessage) — a thin HTTP client is less surface area than a framework plus bundle.

Release-specific note: 1.2.0 introduces no new features and no deprecations of its own, but adding explicit void return types is technically a signature change. Any in-house subclass overriding the affected methods without a return type will need a one-line fix. Low risk, worth a grep before bumping.

How to Pitch It (Stakeholders)

To executives: This is a routine maintenance release for the Telegram integration layer — no new features, no breaking changes, no cost. Its value is schedule protection: it keeps our bot tooling compatible with PHP 8.4 and Symfony 8, so upcoming platform upgrades aren't blocked by this dependency. Recommendation: take the patch on the normal cadence, treat the dependency as supported but small-vendor, and avoid making it load-bearing for customer-facing commitments without an internal wrapper.

To engineering: 1.2.0 is a compatibility bump — void return types to silence PHP 8.4 deprecations, and Symfony 8 support. Bump it during your next dependency refresh, and grep for subclasses of bundle/Nutgram classes that override the touched methods, since tightened signatures can break overrides that omit return types. If you're on Laravel, this bundle is not the right entry point — flag it and use the Laravel-side integration instead. Keep bot logic behind our own adapter service so a future swap or a maintenance gap in the upstream project is a contained change rather than a rewrite.