Symfony Flex, what your symfony 4 application will look like
Symfony 4.0 will be released at the end of November 2017. The next few weeks will post articles about new ideas and major changes in symfony 4.
Symfony 3.0 was boring and was a more concise version of Symfony 2.8:
Symfony 3.0 = Symfony 2.8 - Deprecated Features.
But what will Symfony 4.0 be like in contrast to previous versions:
Symfony 4.0 = Symfony 3.4 - Deprecated Features + New Application Development Concepts.
')
Or here's another scenario:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x - Deprecated Features + New application development concepts.
But most importantly, Symfony 4.0 will require PHP 7. And now for new development concepts.
At the moment, installing a new bundle with a single composite is often not enough.
As it usually happens:
It is not possible to automate the first step, although it is felt that the process itself can be made more convenient for the final developer.
Now look at the 3 and 4 stages. The process of registering configs for new bundles is quite realistic to automate, but most likely it will look like a regular insert of a standard set of settings for a bundle, in which it can function stably, as is done in Symfony Standart Edition for some pre-installed packages.
After all, if you take a look at the README of any popular bandl: they all start with the same tambourine dances - how to configure what you just installed.
If you need to remove the third-party symphony bandl that you recently installed, then you will not need to make composer remove symfony / bundle. Remember that we need to do when installing a new bundle? Well, now we need to manually delete everything that we had written then.
The symfony team has already attempted to provide developers with a definite starting point to start developing certain types of web applications.
The most popular type of web application is the usual traditional applications that we are used to seeing. They use a database, a template system, maybe they even send emails to their users.
But what if you want to make an API or Web Service? Or maybe you want your own Micro Framework Style?
Of course, Symfony Standart Edition provides some choice to the developer, but for a quick start and complete freedom, we will either miss something or vice versa - we end up with too many unnecessary dependencies. Distributions for symfony do not scale: there is no possibility to flexibly add necessary dependencies to a project that were not pre-installed, but needed for full-fledged operation, and there is no way to quickly get rid of unnecessary ones.
Another issue with distributions is that you probably do not want to store files like LICENSE and README in your projects. Many projects do not have a MIT license at all, as can often not be necessary in the README.
A few years ago, Symfony Standart Edition provided a small demo for a quick start, but we removed it after people had some difficulty in removing unnecessary things in the project. It was a good and bad decision.
Not convinced yet? Look at the README REST distribution:
And, probably, therefore Symfony distributions never took off. In addition to the Standart Edition, none of them is popular, so we published only 3 of them:
Hello World Edition, Symfony CMF Standard Edition, Symfony REST Edition.
Distributions themselves are not flexible enough, they can not develop. Distributions are an incorrect abstraction. We do not need a fully loaded project, we need the ability to develop and complement our application over time.
As a developer, I want to start with something small, without a lot of dependencies, in the meantime I want to be able to improve my application as I see fit. From Micro-Framework style to a huge monolith and the framework should not interfere here.
Starting a new project with symfony or modifying an existing one is too difficult for beginners and too cumbersome for advanced developers. We can do better.
Most distributions are Symfony Standart Edition forks with additional bundles. What about composition? What if I want to use the API distribution with Admin? Do I need new distributions here? Probably no.
Symfony Flex is a new way to create and maintain your application with ease. This is what simplifies the creation of applications of any type, from the simplest projects in the Micro-Framework Style, to projects with a huge number of dependencies. It automates the addition and removal of packages, takes care of setting a reasonable configuration for a new package without your participation, and much more.
Symfony Flex will be the default for managing applications on Symfony 4, however it will be available as an optional component for managing applications on Symfony 3.3 and 3.4. The alpha version of symfony flex will be released before the release of symfony 4.
Stay tuned, the next post will tell you more about symfony flex. For now, let's evaluate the new skeleton of the application with symfony Flex . Not exactly what you expected, right?
Symfony 3.0 was boring and was a more concise version of Symfony 2.8:
Symfony 3.0 = Symfony 2.8 - Deprecated Features.
But what will Symfony 4.0 be like in contrast to previous versions:
Symfony 4.0 = Symfony 3.4 - Deprecated Features + New Application Development Concepts.
')
Or here's another scenario:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x - Deprecated Features + New application development concepts.
But most importantly, Symfony 4.0 will require PHP 7. And now for new development concepts.
Symfony has a rather cumbersome installation process for external bundles:
At the moment, installing a new bundle with a single composite is often not enough.
As it usually happens:
- Downloading required dependencies through composer require symfony / bundle
- Register a bundle in app / AppKernel.php
- Registration of routes provided by our new bundle, if any
- Register the required settings for the bundle in app / config / config.yml
It is not possible to automate the first step, although it is felt that the process itself can be made more convenient for the final developer.
Now look at the 3 and 4 stages. The process of registering configs for new bundles is quite realistic to automate, but most likely it will look like a regular insert of a standard set of settings for a bundle, in which it can function stably, as is done in Symfony Standart Edition for some pre-installed packages.
After all, if you take a look at the README of any popular bandl: they all start with the same tambourine dances - how to configure what you just installed.
Removing the bundle in symfony is even more pain
If you need to remove the third-party symphony bandl that you recently installed, then you will not need to make composer remove symfony / bundle. Remember that we need to do when installing a new bundle? Well, now we need to manually delete everything that we had written then.
The Symfony Standart Edition is also not so good
The symfony team has already attempted to provide developers with a definite starting point to start developing certain types of web applications.
The most popular type of web application is the usual traditional applications that we are used to seeing. They use a database, a template system, maybe they even send emails to their users.
But what if you want to make an API or Web Service? Or maybe you want your own Micro Framework Style?
Of course, Symfony Standart Edition provides some choice to the developer, but for a quick start and complete freedom, we will either miss something or vice versa - we end up with too many unnecessary dependencies. Distributions for symfony do not scale: there is no possibility to flexibly add necessary dependencies to a project that were not pre-installed, but needed for full-fledged operation, and there is no way to quickly get rid of unnecessary ones.
Another issue with distributions is that you probably do not want to store files like LICENSE and README in your projects. Many projects do not have a MIT license at all, as can often not be necessary in the README.
A few years ago, Symfony Standart Edition provided a small demo for a quick start, but we removed it after people had some difficulty in removing unnecessary things in the project. It was a good and bad decision.
Not convinced yet? Look at the README REST distribution:
The concept of the distribution is not very suitable symfony
And, probably, therefore Symfony distributions never took off. In addition to the Standart Edition, none of them is popular, so we published only 3 of them:
Hello World Edition, Symfony CMF Standard Edition, Symfony REST Edition.
Distributions themselves are not flexible enough, they can not develop. Distributions are an incorrect abstraction. We do not need a fully loaded project, we need the ability to develop and complement our application over time.
Perfect option
As a developer, I want to start with something small, without a lot of dependencies, in the meantime I want to be able to improve my application as I see fit. From Micro-Framework style to a huge monolith and the framework should not interfere here.
Starting a new project with symfony or modifying an existing one is too difficult for beginners and too cumbersome for advanced developers. We can do better.
Composition inheritance
Most distributions are Symfony Standart Edition forks with additional bundles. What about composition? What if I want to use the API distribution with Admin? Do I need new distributions here? Probably no.
Symfony Flex is a new way to create and maintain your application with ease. This is what simplifies the creation of applications of any type, from the simplest projects in the Micro-Framework Style, to projects with a huge number of dependencies. It automates the addition and removal of packages, takes care of setting a reasonable configuration for a new package without your participation, and much more.
Symfony Flex will be the default for managing applications on Symfony 4, however it will be available as an optional component for managing applications on Symfony 3.3 and 3.4. The alpha version of symfony flex will be released before the release of symfony 4.
Stay tuned, the next post will tell you more about symfony flex. For now, let's evaluate the new skeleton of the application with symfony Flex . Not exactly what you expected, right?
Source: https://habr.com/ru/post/325658/
All Articles