Symfony UX Bundle

[Kocal]

Following the discussions at #3203, let's open a new RFC for the Symfony UX Bundle!

This is something the UX team has been thinking about privately for a while, but opening a public RFC can only be beneficial (rather than volatile Slack messages or verbal discussions 😇 ).

---

Similar to the FrameworkBundle, the UX Bundle would allow Symfony UX packages to be automatically configured in a Symfony application.

This would have the following advantages:

• centralizing the configuration of Symfony UX packages,
• pooling certain logic, e.g., “is AssetMapper installed?”, “add this path to AssetMapper,” etc.,
• and reducing the PHP “glue” code to register a Symfony UX package in a Symfony application.
• and more

Steps

Plan for 2.X

I would like the UX Bundle to be available (and optional) for version 2.x.

This way, we could work on BC layers and tell users that directly registering a bundle (e.g., UxTranslatorBundle in bundles.php) is deprecated, as are the associated DependencyInjection/*.php classes.

Instead, we could suggest installing the Symfony UX Bundle.

This will require, for each UX package:

• deprecating *Bundle.php and its associated classes (mainly Configuration.php, *Extension.php, etc.)
• duplicating and adapting the Configuration in the UXBundle, under the configuration ux_bundle.<package>
• duplicating the config/services.php and renaming them config/<package>.php
• ...more?

EDIT: let's skip this for 2.x!

Plan for X.0

For the next major version, we should:

• identify which package can be migrated to "component"
• move config/* files
• migrate and delete *Bundle.php and associated DependencyInjection classes
• ...more?

Symfony Recipes

All Symfony recipes for Symfony UX will need to be adapted, if possible as soon as UX Bundle is released in 2.x..
Last version of 2.x recipes must be duplicated and adapter to 3.0, e.g.: configuration ux_translator will become becomes ux.translator.

---

Q&A

Q: What about the StimulusBundle?
Should we adapt the existing the StimulusBundle, or create a new package?

A: ???

Q: When someone installs a dependency in major version X, is the recipe for major version X-1 applied? If not, we will need to duplicate our previous recipes in 3.0.

To investigate.

A: We will duplicate the recipe for UX 3.0.

Q: Did I miss something?

A: Tell me! :D

[smnandre]

I'm strongly opposed to introducing the UX bundle in 2.x, and I'm honestly a bit shocked by this.

We agreed months ago to release 3.x first, to clear all deprecations and reduce the legacy we're carrying, and only then build new features on top of it.

For my part, I won't be submitting any new features to 2.x

The first half of this year, spent fixing old bugs and maintaining features/components I neither like nor recommend.. and handling the whole security-issues period, has taken a real toll on my mental health.

For many reasons, I now need to look forward rather than back, and I want to focus on the work I enjoy and believe in: developing new features, improving DX, integration between the UX components and outside libraries, bundle, standards.

[Kocal]

I'm fine for no BCP layer, that would make things easier for us.

I will edit the issue description ASAP

[Kocal]

Original description updated, we still need to figures out:

1. should we create a new package for that?
2. Symfony provides Bundles and Components in https://github.com/symfony/symfony, do we have some packages that can't become components but must stays bundles?