Inwx Api Bundle Laravel Package

Getting Started

• Install with Composer and confirm the Symfony Console constraint:

  composer require vendor/package:^1.0
  composer why symfony/console
  

• v1.0.1 is a compatibility patch for Symfony 4.x signature handling. If you are already on Symfony 4.x, upgrade from 1.0.0; if you are pinned to Symfony 3.4, run your command tests before and after upgrading.
• First places to look:
  • the package README for command examples and required registration;
  • composer.json for symfony/console / Laravel version constraints;
  • the package service provider to confirm auto-discovery or manual registration.
• Minimal first use case: define one Artisan command using the package's signature/command API, register it, then verify both discovery and parsing:

  php artisan list
  php artisan your:command --help
  php artisan your:command example-argument --verbose
  

Implementation Patterns

• Keep command definitions declarative using protected $signature and protected $description. Treat argument and option names as a public API once scheduled or called by other code.
• Register commands either in app/Console/Kernel.php via $commands or through the package's service provider. Prefer one registration path per codebase.
• Resolve dependencies through the container in handle() and read input through $this->argument() / $this->option() rather than reaching into Symfony internals.
• Use Laravel's command testing helpers for day-to-day confidence:

  $this->artisan('your:command', ['name' => 'value', '--flag' => true])
      ->expectsOutput('Done')
      ->assertExitCode(0);
  

• When scheduling, call the same command name used in php artisan list; avoid duplicating command logic in closures.
• For programmatic invocation, use Artisan::call() and Artisan::output() rather than constructing Symfony command objects directly.
• If the package exposes a command base class or signature parser, wrap it in a small application-level base command so future Symfony compatibility changes are isolated.
• Publish and commit any package config before relying on defaults; environment-specific values should come from config/ or .env, not command signatures.

Gotchas and Tips

• The v1.0.1 fix is specifically about Symfony 3.4 → 4.x signature differences. Check the resolved symfony/console version in composer.lock; a mixed dependency tree can still install a version the package did not expect.
• Signature syntax is sensitive to whitespace, quoting, and default-value formatting. After changing a signature, run php artisan your:command --help and confirm the generated arguments/options rather than assuming parsing succeeded.
• Common signature mistakes:
  • {arg} required vs {arg?} optional;
  • {--opt=} value-required vs {--opt=*} array;
  • defaults containing spaces must be quoted correctly;
  • option shortcuts that collide with Laravel or Symfony global options.
• Do not depend on $this->input internals or Symfony InputDefinition object shape across major Symfony versions. Favor argument() / option() and explicit validation.
• If a command disappears from php artisan list, check auto-discovery, config/app.php providers, app/Console/Kernel.php, and run:

  composer dump-autoload
  php artisan config:clear
  php artisan cache:clear
  

• Debug parsing and runtime failures with -vvv; catch Symfony\Component\Console\Exception\RuntimeException for missing arguments and InvalidArgumentException for bad option definitions.
• Test command output assertions against the Laravel/Symfony versions you actually deploy. Output formatting and exception messages can differ between Symfony 3.4 and 4.x.
• Extension points to prefer: overriding configure() for dynamic definitions, binding a custom command loader, or wrapping the package parser in your own service. Avoid patching vendor code for signature compatibility.
• When upgrading Laravel or Symfony, run the package's command tests first, then php artisan list, then scheduled-command smoke tests. The signature layer is the most likely place for a silent behavioral change.