Deprecation warning when repacking a PHAR with Castor (Symfony Console 7.4 add() deprecation)

[arnolem]

Description

While following the official documentation to extend Castor and repack it as a PHAR, I am consistently getting Symfony deprecation warnings during the PHAR build and when executing the generated PHAR.

The warnings are related to Symfony\Component\Console\Application::add() being deprecated since Symfony Console 7.4.

This is problematic because:

• the warning is displayed during castor repack
• the warning is also displayed every time the PHAR is executed
• the warning is repeated once per command, which is quite noisy for end users

---

Steps to reproduce

I followed exactly this documentation page:
https://castor.jolicode.com/docs/going-further/extending-castor/repack/

1. Initialize a new Composer project

composer init

Composer output:

Generating autoload files
Generated autoload files
PSR-4 autoloading configured. Use "namespace Arnaud\CastorBuild;" in src/
Include the Composer autoloader with: require 'vendor/autoload.php';

---

2. Install Castor as a dependency

composer require jolicode/castor

Relevant output:

Locking symfony/console (v7.4.1)
Locking symfony/config (v7.4.1)
Locking symfony/dependency-injection (v7.4.2)
Using version ^1.1 for jolicode/castor

---

3. Initialize Castor and create a simple task

vendor/bin/castor

Castor creates a castor.php file with a basic Hello task.

---

4. Repack Castor as a PHAR

vendor/bin/castor repack

⚠️ Deprecation warning appears here:

WARNING   [castor] User Deprecated: Since symfony/console 7.4:
The "Symfony\Component\Console\Application::add()" method is deprecated
and will be removed in Symfony 8.0, use
"Symfony\Component\Console\Application::addCommand()" instead.

---

5. Execute the generated PHAR

./my-app.linux.phar

⚠️ The same warning is displayed again, and it is repeated once per command:

WARNING   [castor] User Deprecated: Since symfony/console 7.4:
The "Symfony\Component\Console\Application::add()" method is deprecated
and will be removed in Symfony 8.0, use
"Symfony\Component\Console\Application::addCommand()" instead.

---

Expected behavior

• No Symfony deprecation warnings should be displayed:

  • during castor repack
  • when running the generated PHAR

• Especially not in a distributed PHAR intended for end users

---

Actual behavior

• Deprecation warnings are printed:

  • during PHAR creation
  • every time the PHAR is executed

• The warning is repeated for each registered command

---

Additional context

It looks like Symfony 7.4 is being installed by Composer, while Castor itself appears to normally embed Symfony 7.3, as mentioned in this issue comment:

#751 (comment)

Because Application::add() is deprecated in Symfony Console 7.4, this leads to visible deprecation warnings when repacking and running the PHAR.

I’m not sure if:

• Castor should pin Symfony Console to <7.4, or
• Castor’s internal usage of Application::add() should be updated to addCommand(), or
• the repack process should suppress user deprecations

But in the current state, following the official documentation leads to a PHAR that emits deprecation warnings at runtime.

---

Environment

• OS: Linux / WSL2
• PHP: PHP 8.4.15 (cli) (built: Nov 20 2025 17:43:25) (NTS
• Castor: ^1.1
• Symfony Console: 7.4.x (installed via Composer)

Request for guidance

It is also possible that I am misunderstanding the recommended workflow or that I am not using the repack feature correctly.
If that’s the case, I would really appreciate some guidance on the correct way to proceed in order to avoid these warnings.

Please let me know if I missed an important step, if additional configuration is required, or if this behavior is actually expected when extending and repacking Castor.

Thanks in advance for your help and for the great work on Castor 🙏

[arnolem]

Additional note about Symfony Console version resolution

Looking at Castor’s composer.json, the dependency is defined as:

"symfony/console": "^7.3.6"

This constraint currently resolves to Symfony Console 7.4.x, which explains why the deprecation warning appears (Application::add() being deprecated since 7.4).

As a test, I forced Symfony Console 7.3.x in my project:

composer require symfony/console:7.3.*

With this constraint:

• the deprecation warning disappears during castor repack
• and it also disappears when running the generated PHAR

This seems to confirm that the issue is directly related to Symfony Console 7.4 being resolved by Composer with the current constraints.

[joelwurtz]

It will be fixed in next release since we updated to sf 7.4 and fix deprecations here : #769

In the mean time you can restrict to use symfony 7.3 (by adding your own rule to your compose file)

@lyrixx @pyrech should we hide deprecations by default ? (and show them with versbose for example) to avoid problem like this in this future ?

[lyrixx]

@lyrixx @pyrech should we hide deprecations by default ? (and show them with versbose for example) to avoid problem like this in this future ?

I don't think so

[arnolem]

Why not lock the Symfony versions on your side and perform the upgrades manually when you're ready?

I find it strange to say that you're only compatible with Symfony 7.3 while users end up with version 7.4.

[joelwurtz]

We were already ready for sf 7.4, it is just a depreciation ? Locking would also mean that some people may not upgrade their library if they use castor as a dependency, in both cases someone would not be happy, but at least in our case if you want to stick with sf 7.3 it's an easy fix.

Futhermore, castor is mainly distributed as a phar / static so this problem only appear if you need to repack.

I think we will change the way we repack to avoid requiring castor.

[lyrixx]

The issue here is different. People should not install composer along with regular project dependencies. I know this is what we tell in the docs.

This is a bad idea. We must find another way to re-build a phar from the currently installed version of castor.

It will avoid this kind of error and ensure castor version are the very same.

I don't remember why I did that in the first place. I should give it another try