Short guide explaining how to migrate from Silex to Symfony 4+ Flex

[javiereguiluz]

Silex ends as a project in June 2018. Lots of people still using it. Even if Sf4 + Flex ideas are pretty similar to Silex, it takes some time to learn the new concepts and philosophy.

Could we prepare a short upgrading guide for Silex users? It wouldn't be a comprehensive and ultra detailed guide, just a quick overview of the main changes: where to put the app config, how to define services, controllers + routes with annotations, etc.

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

[pdelmoral]

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

• Dependency Injection
• Routes

[pdelmoral]

If you are a Silex developer, please add a comment here telling us what would be the most important things to explain. Thanks!

• Dependency Injection
• Routes

[mathieuimbert]

• Security Firewalls
• Services & autowiring
• Middlewares

[mathieuimbert]

• Security Firewalls
• Services & autowiring
• Middlewares

[antoniocambados]

I should be migrating a project pretty soon. Not that these are particularly hard to migrate in my case, but my main concerns are:

• Migrating middlewares
• Turning services and service providers into Symfony services

[antoniocambados]

I should be migrating a project pretty soon. Not that these are particularly hard to migrate in my case, but my main concerns are:

• Migrating middlewares
• Turning services and service providers into Symfony services

[GawainLynch]

My First Upgrade from Silex 2 to Symfony 4 / Flex

This is just a few notes on the way I approached my first cut-over of a project from Silex to Symfony 4 & Flex. The most important thing I think I would point out for those of us very used to Silex is:

• Rule #1 … Don't fear the change, embrace it!

Stuff might feel "different" or "unnatural" at first, but you quickly adapt and grow attached to the change.

Before you go too far, give this a good read:

• Service container

… don't try to "get" everything now, but having some of it in your mental view will help a lot of this "click" pretty quickly.

Next thing I found valuable was to composer create-project symfony/skeleton && cd skeleton && php -S 127.0.0.1:8000 -t public and have a look at what you've got … a very simple starting point.

Then I did a bunch of composer requires to start adding the external dependencies I knew I was going to require and in a few minutes I had the beginning of what I needed to start porting my Silex project, things like:

• composer.json
  • "require"
  • "require-dev"
  • "config"
  • "scripts"
• symfony.lock
• bin/console
• config/*
• public/index.php
• src/Kernel.php
• .env
• .env.dist

A huge wall you can hit at this point is copying these over, pressing F5 in your browser and watching everything crash. 😄

What I chose to do at this point was to edit my config/services.yaml file and comment out this section:

    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Repository,Tests}'
    App\Controller\:
        resource: '../src/Controller'
        tags: ['controller.service_arguments']

That stopped the DI compiler from scanning every class in src/ and causing a lot of pain trying to port your service classes over.

HUGE NOTE: This approach circumvents a lot of what makes autowiring awesome, you wouldn't normally do this on a new project, but it also allows you to slowly progress though your migration without too much pain.

Important tip, you two best friends at this point in time:

• ./bin/console debug:container
• ./bin/console debug:autowiring

😉

Next, I went through each of my own project's service providers and added the services one by one (as needed) to config/services.yaml

For example, a Twig extension's runtime class:

    App\Twig\Extension\MyRuntime:
        autowire: true
        tags:
            - { name: twig.runtime }

Once you have your base serviced looking like they're wired up, move onto your controllers. I enabled them in my config/services.yaml
one at a time like so:

    App\Controller\MyFirstController:
        tags: ['controller.service_arguments']

The allowed me to step through each one, get it loading and move on. Depending on dependencies you might have to jump through a few iterations of this process.

Depending on the size and complexity of your project, this should get a lot of them close to cut-over. My first one was less than two hours to migrate.

[GawainLynch]

My First Upgrade from Silex 2 to Symfony 4 / Flex

This is just a few notes on the way I approached my first cut-over of a project from Silex to Symfony 4 & Flex. The most important thing I think I would point out for those of us very used to Silex is:

• Rule #1 … Don't fear the change, embrace it!

Stuff might feel "different" or "unnatural" at first, but you quickly adapt and grow attached to the change.

Before you go too far, give this a good read:

• Service container

… don't try to "get" everything now, but having some of it in your mental view will help a lot of this "click" pretty quickly.

Next thing I found valuable was to composer create-project symfony/skeleton && cd skeleton && php -S 127.0.0.1:8000 -t public and have a look at what you've got … a very simple starting point.

Then I did a bunch of composer requires to start adding the external dependencies I knew I was going to require and in a few minutes I had the beginning of what I needed to start porting my Silex project, things like:

• composer.json
  • "require"
  • "require-dev"
  • "config"
  • "scripts"
• symfony.lock
• bin/console
• config/*
• public/index.php
• src/Kernel.php
• .env
• .env.dist

A huge wall you can hit at this point is copying these over, pressing F5 in your browser and watching everything crash. 😄

What I chose to do at this point was to edit my config/services.yaml file and comment out this section:

    App\:
        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Repository,Tests}'
    App\Controller\:
        resource: '../src/Controller'
        tags: ['controller.service_arguments']

That stopped the DI compiler from scanning every class in src/ and causing a lot of pain trying to port your service classes over.

HUGE NOTE: This approach circumvents a lot of what makes autowiring awesome, you wouldn't normally do this on a new project, but it also allows you to slowly progress though your migration without too much pain.

Important tip, you two best friends at this point in time:

• ./bin/console debug:container
• ./bin/console debug:autowiring

😉

Next, I went through each of my own project's service providers and added the services one by one (as needed) to config/services.yaml

For example, a Twig extension's runtime class:

    App\Twig\Extension\MyRuntime:
        autowire: true
        tags:
            - { name: twig.runtime }

Once you have your base serviced looking like they're wired up, move onto your controllers. I enabled them in my config/services.yaml
one at a time like so:

    App\Controller\MyFirstController:
        tags: ['controller.service_arguments']

The allowed me to step through each one, get it loading and move on. Depending on dependencies you might have to jump through a few iterations of this process.

Depending on the size and complexity of your project, this should get a lot of them close to cut-over. My first one was less than two hours to migrate.

[sedatsevgili]

We have an enterprise-level silex app and looked a way to convert only the framework layer about 2 weeks ago.

1. We did not have any problem about composer dependencies. Everything was ok for our 3rd party libs.
2. Autowiring and autoconfiguring was so helpful.
3. We had to define a public snc_redis.cache alias in services.yaml (because we had to get it from container directly).
4. Created a facade for the \Silex\Application. Because of we wired manually so many things into it and used it in our so many controllers & services, we have to create a facade of it.
5. Translation just did not work. I don't know why but giving path of our resources did not help.
6. We could not find an easy way to convert and use custom middlewares in the Symfony stack.
7. We did not use env variables. Instead of it, used our custom config things.
8. Profiler was ok in our dev environment. However could not profile any dql. There was an issue about that maybe dont exist any more.
9. You have to check Bundle compatibility

[sedatsevgili]

We have an enterprise-level silex app and looked a way to convert only the framework layer about 2 weeks ago.

1. We did not have any problem about composer dependencies. Everything was ok for our 3rd party libs.
2. Autowiring and autoconfiguring was so helpful.
3. We had to define a public snc_redis.cache alias in services.yaml (because we had to get it from container directly).
4. Created a facade for the \Silex\Application. Because of we wired manually so many things into it and used it in our so many controllers & services, we have to create a facade of it.
5. Translation just did not work. I don't know why but giving path of our resources did not help.
6. We could not find an easy way to convert and use custom middlewares in the Symfony stack.
7. We did not use env variables. Instead of it, used our custom config things.
8. Profiler was ok in our dev environment. However could not profile any dql. There was an issue about that maybe dont exist any more.
9. You have to check Bundle compatibility

[derrabus]

We could not find an easy way to convert and use custom middlewares in the Symfony stack.

Middlewares are just event listeners under the hood. You should be able to convert all of your middlewares to event subscribers before migrating to Symfony.

Examples:

• opencfp/opencfp#867
• opencfp/opencfp#888

[derrabus]

We could not find an easy way to convert and use custom middlewares in the Symfony stack.

Middlewares are just event listeners under the hood. You should be able to convert all of your middlewares to event subscribers before migrating to Symfony.

Examples:

• opencfp/opencfp#867
• opencfp/opencfp#888

[derrabus]

I have prepared a small script to export routes from a Silex application. Maybe this is helpful for someone here: https://gist.github.com/derrabus/4d7b7b3a6ffc0c1ccc1037ce2a66b13c

[derrabus]

I have prepared a small script to export routes from a Silex application. Maybe this is helpful for someone here: https://gist.github.com/derrabus/4d7b7b3a6ffc0c1ccc1037ce2a66b13c

[lsmith77]

opencfp/opencfp#895

[lsmith77]

opencfp/opencfp#895

[FbN]

Learned today about SILEX dead sentece. If you don't like Synfony 4 I think SLIM is a great alternative very similar to Silex. Is micro, is based on Pimple, it's PSR7, has middleware support, have a great community. I think would very easy to migrate from silex to slim, maybe easier than to Symfony 4.

[FbN]

Learned today about SILEX dead sentece. If you don't like Synfony 4 I think SLIM is a great alternative very similar to Silex. Is micro, is based on Pimple, it's PSR7, has middleware support, have a great community. I think would very easy to migrate from silex to slim, maybe easier than to Symfony 4.

[MaPePeR]

@FbN not sure about that "easier to SLIM than Symfony 4/Flex":

• SLIM does not have argument resolving for Controllers if i read the documentation correctly. So one would have to touch every Controller and do the Argument resolving manually.
• The Syntax for defining routes is similar, but not identical. At least assert and default values are different. So one would need to touch every Route.
• The "Middleware"-Feature is implemented in a totally different way, so one has to bascially reimplement them.

There are probably a lot more points i'm not even aware of, yet.

EDIT: I'm not really awake, yet, so i forgot to think about how these "difficult" migration steps actually compare to what one has to do to migrate to Symfony 4/FLEX.

[MaPePeR]

@FbN not sure about that "easier to SLIM than Symfony 4/Flex":

• SLIM does not have argument resolving for Controllers if i read the documentation correctly. So one would have to touch every Controller and do the Argument resolving manually.
• The Syntax for defining routes is similar, but not identical. At least assert and default values are different. So one would need to touch every Route.
• The "Middleware"-Feature is implemented in a totally different way, so one has to bascially reimplement them.

There are probably a lot more points i'm not even aware of, yet.

EDIT: I'm not really awake, yet, so i forgot to think about how these "difficult" migration steps actually compare to what one has to do to migrate to Symfony 4/FLEX.

[derrabus]

Please don't turn this thread into a framework battle.

[derrabus]

Please don't turn this thread into a framework battle.

[p3x-robot]

I was thinking I would migrate to Symfony 4, but it so much complex just a few routes and I have to add in yml, services, console, do not need it at all, it is already overloaded by using twig anyway, I will keep Silex, it is complete as it is.
Silex = microframework
Symfony = macroframework

[p3x-robot]

I was thinking I would migrate to Symfony 4, but it so much complex just a few routes and I have to add in yml, services, console, do not need it at all, it is already overloaded by using twig anyway, I will keep Silex, it is complete as it is.
Silex = microframework
Symfony = macroframework