tomatom/atom-bundle
A Symfony bundle from TomAtom that packages Atom functionality as a reusable extension, making it easier to wire Atom features into Symfony applications through standard bundle configuration and services.
What this package is. tomatom/atom-bundle is a Symfony bundle (GPL-2.0, single maintainer, ~4 stars, zero known dependents). Treat it as a small, opinionated glue bundle rather than framework infrastructure: the value is in whatever services, compiler passes, or config it ships, not in a stable public API you can lean on for years.
Install and register.
composer require tomatom/atom-bundle
There is almost certainly no Symfony Flex recipe, so registration is manual. Add it to config/bundles.php:
return [
// ...
TomAtom\AtomBundle\AtomBundle::class => ['all' => true],
];
Then clear cache and confirm the container still compiles — that single step is the fastest smoke test for a bundle of this size:
php bin/console cache:clear
php bin/console lint:container
Where to look first, in this order:
vendor/tomatom/atom-bundle/README.md — the only authoritative usage docs you have.src/AtomBundle.php — reveals the namespace, whether it registers compiler passes, and whether it extends AbstractBundle (new-style config) or the classic Bundle + Extension pair.src/DependencyInjection/Configuration.php — the exact config tree. Do not guess config keys; copy them from here.src/DependencyInjection/AtomBundleExtension.php — what gets wired and under which service IDs.tests/ — the best documentation for intended usage; if this directory is empty or thin, lower your expectations accordingly.First use case. Wire it into one bounded piece of your app before anything else — a single console command or one controller action — and verify the container resolves the services. Do not put it on a hot path or in a shared base project until you have read the source end to end (it is small enough that this takes under an hour, and that hour is the actual due-diligence cost of adopting this bundle).
Pin the version explicitly. With zero dependents and one maintainer, a floating constraint is a liability. Require a specific tag in composer.json and commit the lock file:
"require": { "tomatom/atom-bundle": "1.0.*" }
Check the tag's date against its changelog before trusting it — the advertised last release (2026-07-31) is anomalous, so verify what composer show tomatom/atom-bundle actually resolves on your PHP/Symfony pair.
Configure, don't hardcode. Once you know the tree from Configuration.php, set it in config/packages/atom.yaml and keep environment-specific values in .env:
# config/packages/atom.yaml
atom:
# keys taken verbatim from src/DependencyInjection/Configuration.php
some_option: '%env(ATOM_SOME_OPTION)%'
Prefer constructor injection of its services over pulling from the container. Enumerate what it exposes, then alias the useful services to your own interfaces so the dependency stays swappable:
php bin/console debug:container --show-private TomAtom
// config/services.yaml
services:
App\Contract\Something: '@TomAtom\AtomBundle\Service\SomeService'
That alias is your escape hatch: if the bundle is abandoned or the GPL becomes a problem, you reimplement one interface instead of chasing call sites.
Wrap it in an adapter layer. For anything beyond trivial use, put a thin App\Atom\Client (or similarly named) facade in front of the bundle's API. This gives you a stable seam for testing, lets you stub the dependency in unit tests, and localizes any upgrade breakage to one file. It also keeps GPL-licensed types out of the constructor signatures of your own domain services — relevant if the rest of your codebase is proprietary.
Integration tips.
vendor/ does not.Resources/config/services.xml with explicit arguments, which means your overrides need matching IDs.debug:event-dispatcher and list respectively.License is the biggest real risk. GPL-2.0 is copyleft and is unusual for a Symfony bundle. If your application is proprietary, get a legal read before shipping — linking GPL code into a distributed PHP app is a genuine question, not a formality. This alone disqualifies it for many commercial projects.
Bus factor of one. One maintainer, ~4 stars, zero dependents means no downstream ecosystem is exercising this code in production. Assume no timely security fixes. Mitigations: pin the version, vendor the source if necessary, or plan to replace it. Never put it in a shared internal starter kit without a named owner.
Version constraints will bite. Confirm the composer.json require block against your PHP version and Symfony major (bundle APIs shifted materially between Symfony 5, 6, and 7 — AbstractBundle vs Extension, attribute-based routing, etc.). A four-star bundle is often pinned to one Symfony major.
No recipe means no automatic config. You will not get config/packages/atom.yaml generated, and cache:clear failures after install usually mean a missing required config key. Read Configuration.php for isRequired() / cannotBeEmpty() nodes first.
Debugging playbook:
php bin/console debug:config atom # what config actually resolved
php bin/console debug:container --tag=atom # or grep for TomAtom
php bin/console lint:container # catches constructor arg mismatches early
If debug:config atom throws "no extension able to load", the bundle isn't registered or is registered under the wrong name (alias mismatch between the extension's getAlias() and your YAML root key).
Extension points are undocumented. Where the README is silent, look for interfaces, *Interface types, and final/@internal annotations in src/. Anything marked @internal is not an extension point, even if it's technically public — expect it to change.
Test the upgrade path before adopting. Install the previous tag, then the latest, and read the diff. With no dependents and no changelog discipline, breaking changes ship as patch or minor releases. Your own test suite is the only regression net you'll have.
How can I help you explore Laravel packages today?