A week of symfony #536 (3-9 April 2017)

April 9, 2017 · Published by Avatar of Javier Eguiluz Javier Eguiluz

This week Symfony started working on stabilizing the new features introduced for Symfony 3.3, specially the ones related to autowiring. Symfony also added a new Kernel::getProjectDir() method to get the root directory of the project instead of the kernel directory. Lastly, the first blog posts about Symfony 4 were published, outlining the future of the Symfony project.

Symfony development highlights

2.7 changelog:

  • c7163e2: [DependencyInjection] fixed fatal error at ContainerBuilder::compile() if config is not installed
  • a9da8a3: [ExpressionLanguage] provide the expression in syntax errors
  • a2cd63c: fixed more risky tests
  • a200357: [Translation] avoid creating cache files for fallback locales
  • 933835c: [DependencyInjection] fixed the XML schema
  • 2adfb37: [Validator] check for empty host when calling checkdnsrr
  • 0eed690: [ExpressionLanguage] avoid ExpressionLanguage dependency on ctype

2.8 changelog:

  • ee10bf2: [DependencyInjection] don't use auto-registered services to populate type-candidates
  • bad24d3: [DependencyInjection] autowiring and factories are incompatible with each others
  • 91b025a: [DependencyInjection] prevent AutowirePass from triggering irrelevant deprecations

3.2 changelog:

  • 80cea46: [PropertyInfo] supported nullable array or collection
  • 247e797: [PropertyInfo] allow Upper Case property names
  • db8231e: [HttpKernel] fixed forward compat with Request::setTrustedProxies()
  • 91b025a: [DependencyInjection] prevent AutowirePass from triggering irrelevant deprecations

Master changelog:

  • 47740ce: [Workflow] added workflow_marked_places() Twig function
  • 88c587d: [DependencyInjection] don't trigger deprecation for event_dispatcher service
  • 2450449: [DependencyInjection] added ServiceLocatorTagPass::register() to share service locators
  • a146e4d: [FrameworkBundle] returns the kernel instance in KernelTestCase::bootKernel
  • 6e54cdf: [Console] give errors back to error handler if not handled by console.error listeners
  • 54495b2: [Console] allow to catch CommandNotFoundException
  • 2a40b6f: [WebProfiler] fixed race condition in fast Ajax requests
  • 937045c: [Yaml] report deprecations when linting YAML files
  • d33c0ee: [TwigBundle] redesigned the exception pages
  • ab93fea: [DependencyInjection] always autowire "by id" instead of using reflection against all existing services
  • d662b21: [DependencyInjection] restrict autowired registration to "same-vendor" namespaces
  • 3458edf, 49ae724: [DependencyInjection] improved autowiring error messages
  • abb8d2b: [WebServerBundle] added a way to dump current status host/port/address when getting the status
  • 3f07e10: [HttpKernel] dump container logs in Kernel to have them also on errors
  • ec2cc08: [HttpKernel] resolve invokable controllers short notations using ServiceValueResolver
  • f04c0b5: [HttpKernel] skip ContainerAwareInterface::setContainer from service_arguments actions registration
  • 7b8409a: [HttpKernel] added Kernel::getProjectDir()

Newest issues and pull requests

They talked about us

Published in #A week of symfony

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of Adam Prager
Adam Prager said on Apr 10, 2017
Most of Symfony4's new features look awesome, can't wait to try on-demand components and config. :)

I'm not sure about the bundle-less approach though. Sure it will make symfony "friendlier", reduces the learning curve for newcomers, lowers the bar small projects to consider symfony (less overhead, simpler structure). These are very positive points, and the decision is totally understandable.
However I'm wondering about mid+ size project, and project growth. In my experience initial requirements rarely reflect the real complexity of a project.
Let's say I have a bundle-less, mid sized symfony project. The project also has a bunch of CMS features, it would make sense to create a separate bundle for them. Most of the time these bundles are not completely decoupled, not open sourced -> not reused. They exists purely as an organization pattern.
With the AppBundle, this was very easy to do, only a small refactor... basically a namespace change. Will the bundle-less version support this? Or will we have to solve these problems inside our domain (like App\Cms\Entity) ?
What would happen If I had to extend a 3rd party bundle, like FOSUser?

IMO the guidelines should cover scenarios like this. Shouldn't be too hands off...
Avatar of Jarosław Jakubowski
Jarosław Jakubowski said on Apr 12, 2017
In Symfony 4, can you make default configuration directory name configurable? I find /etc to not be explicit enough (I know it originates from Unix's /etc, but not every Symfony Developer is Unix Master ;) ). I would like to easily change it to /config or /conf. Could there be a simple method like getConfigDir() similar to getCacheDir() or getLogDir()?

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.