Lendo Cli Bundle Laravel Package

Getting Started

Install the bundle with Composer (it is a Symfony bundle, so Flex may register it automatically):

composer require lendo-stp-gdansk/lendo-cli-bundle

If Flex does not auto-register it, add the bundle to config/bundles.php:

return [
    // ...
    Lendo\CliBundle\LendoCliBundle::class => ['all' => true],
];

Look first at:

1. The command list — this is the whole point of the package:

   bin/console list
   bin/console list lendo        # if commands use a namespace prefix
   bin/console list | grep -i lendo
   

2. The bundle's DependencyInjection/ directory in vendor/lendo-stp-gdansk/lendo-cli-bundle/ — this tells you the config tree, service IDs, and whether a config file is required (config/packages/lendo_cli.yaml).
3. Each command's configure() method — it documents arguments, options, and defaults far better than most READMEs.

A typical first use case is on-boarding a fresh checkout: run whatever "setup/verify/health" command the bundle ships (e.g. a project bootstrap or environment inspection command) instead of running a dozen manual steps. Confirm it exists with list before wiring it into onboarding docs.

# Clear the cache after install so the container picks up new commands
bin/console cache:clear
bin/console list --raw | grep -i lendo

Implementation Patterns

Discover and inspect before scripting. Use Symfony's built-in introspection to learn a command's contract without reading source:

bin/console help <command-name>
bin/console <command-name> --help
bin/console debug:container --tag=console.command

Wrap commands in a Makefile or Composer scripts. This is the highest-leverage day-to-day pattern: developers should not memorize bundle-specific command names.

lendo-check:
	bin/console <command> --no-interaction

lendo-ci: lendo-check
	bin/console <command> --env=test --no-interaction

{
  "scripts": {
    "post-install-cmd": ["@php bin/console cache:clear"],
    "lendo": ["@php bin/console <command>"]
  }
}

Compose commands in CI pipelines. Console commands are ideal CI steps because they return exit codes and support --no-interaction. Always pass --no-interaction (or -n) in automation — any command that prompts will otherwise hang the pipeline, and use --env=test/--env=prod deliberately, since the bundle may register different commands per environment.

Extend rather than fork. If the bundle exposes base command classes or tagged services, subclass them in src/Command/ and add project-specific behavior. Tag with console.command (or rely on autoconfiguration for Command subclasses) so your subclass participates in the same namespace and inherits the bundle's dependencies:

#[AsCommand(name: 'app:lendo:extended')]
class ExtendedCommand extends \Lendo\CliBundle\Command\SomeBaseCommand
{
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $status = parent::execute($input, $output);
        // project-specific follow-up work
        return $status;
    }
}

Inject bundle services instead of shelling out. If the commands are backed by services, consuming those services directly from your own code/commands is cleaner than invoking bin/console via exec():

services:
  App\Command\MyCommand:
    arguments:
      $client: '@lendo_cli.some_service'

Confirm the real service ID with bin/console debug:container <fragment>.

Use verbosity flags as a debugging workflow. Run with -v, -vv, or -vvv to surface the bundle's internal logging; this is usually faster than attaching a debugger for a first-pass diagnosis.

Gotchas and Tips

• Commands missing after install? Almost always a stale container or an unregistered bundle. Run bin/console cache:clear (and cache:clear --env=prod separately — caches are per-environment), then verify with bin/console debug:container --tag=console.command.
• Environment-scoped registration. Many bundles register commands only in dev or test. If a command works locally but is absent in CI, check the bundle's Extension/CompilerPass for environment guards.
• Config key naming. Symfony bundles normalize extension aliases (e.g. lendo_cli vs lendo-cli). If Symfony reports "There is no extension able to load the configuration for...", check the exact alias in the bundle's getContainerExtension() / Configuration::getConfigTreeBuilder()->rootNode()->name().
• Bundle ordering. If this bundle decorates or depends on another bundle's services, it must be registered after that bundle in config/bundles.php. Ordering issues typically manifest as "service not found" during container compilation.
• Interactive prompts in CI. Any command without --no-interaction is a latent pipeline hang. Add -n defensively even if the command looks non-interactive today.
• Exit codes are the contract. When wrapping commands in shell scripts, propagate the exit code (set -e or || exit $?) rather than swallowing it; CI status depends entirely on this.
• Long-running commands. If a command touches the DB or filesystem in bulk, watch memory with php -d memory_limit=-1 bin/console ... only as a diagnostic — treat recurring OOMs as a signal the command should be batched.
• Low-traffic package. With zero dependents and no stars, treat the API surface as unstable: pin an exact version in composer.json ("lendo-stp-gdansk/lendo-cli-bundle": "1.2.*"), review changelogs on update, and prefer wrapping the bundle behind your own Make targets/services so a breaking change touches one file rather than dozens.
• Vendor path is readable. Since docs are likely thin, vendor/lendo-stp-gdansk/lendo-cli-bundle/ (especially the Command/ directory) is your primary reference. Read configure() for options and execute() for side effects before running anything against a shared database.
• Extension points to look for: tagged services (custom command collectors), compiler passes, and base command classes. These are the supported ways to customize behavior; editing vendor files is not.