Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

javiereguiluz opened this issue Nov 16, 2017 · 14 comments

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

javiereguiluz opened this issue Nov 16, 2017 · 14 comments


Copy link

@javiereguiluz javiereguiluz commented Nov 16, 2017

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!

Copy link

@pdelmoral pdelmoral commented Nov 21, 2017

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
Copy link

@mathieuimbert mathieuimbert commented Dec 1, 2017

  • Security Firewalls
  • Services & autowiring
  • Middlewares
Copy link

@antoniocambados antoniocambados commented Dec 1, 2017

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
Copy link

@GawainLynch GawainLynch commented Dec 2, 2017

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:

… 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 -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:

        resource: '../src/*'
        exclude: '../src/{Entity,Migrations,Repository,Tests}'
        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:

        autowire: true
            - { 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:

        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.

Copy link

@sedatsevgili sedatsevgili commented Dec 4, 2017

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
Copy link

@derrabus derrabus commented Dec 11, 2017

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.


Copy link

@derrabus derrabus commented Dec 20, 2017

I have prepared a small script to export routes from a Silex application. Maybe this is helpful for someone here:

Copy link

@lsmith77 lsmith77 commented Dec 22, 2017

Copy link

@FbN FbN commented Apr 15, 2018

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.

Copy link

@MaPePeR MaPePeR commented Apr 16, 2018

@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.

Copy link

@derrabus derrabus commented Apr 16, 2018

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

Copy link

@p3x-robot p3x-robot commented Aug 31, 2018

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

Copy link

@nicolas-grekas nicolas-grekas commented Apr 24, 2019

Shall we close here? As time passes, this is less and less needed.

Copy link
Member Author

@javiereguiluz javiereguiluz commented Apr 25, 2019

I agree. Let's close this as "won't fix". Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet