Repository navigation
Feature request: Symfony & Twig #25
Description
Activity
That would be great, but it's been many years since I worked with either so I'm not sure I could do a very good job of implementing them.
At minimum I would need good examples and explanations as well as someone to test things. The Symfony docs are pretty good and they are usually less of a spaghetti system then Laravel so there docs should be useful at least.
Would you be able to help with this?
yes, i could even write some code if you want, and ideally port it back to mago as you did with laravel
That would be much appreciated.
If you can create a demo project similar to https://github.com/AJenbo/phpantom_lsp/tree/main/examples/laravel that would be really helpful.
Existing tools, especially if they have tests, under MIT license (likeVimfony) are also helpful. But really a valid Symfony implementation of a demo project would be the next best thing to make short of implementing support and sending a PR.
There is https://github.com/symfony/demo
Reacted by Anders Jenbo and n0ss1g3nI would love if twig was supported on this. The codebase I use has a lot of Twig + Laravel + Legacy PHP and I've been waiting so long to find a LSP that supports all 3. Going to try this LSP at the weekend for a project I am working on.
If you need any help understanding how to find information about some symfony things (Using the built-in console or the xml container file), feel free to ask.
You might also want to take a look at the PHPStorm Symfony plugin.
The Symfony team shares information about upcoming features of Symfony with Jetbrains to keep Symfony plugin up to date.There's for example some special phpstan tags for easier autocompletion : https://www.jetbrains.com/help/phpstorm/symfony-creating-helper-functions.html#hashes
If you want to implement it with php calls at runtime :
To get routes information :
php bin/console debug:router --format=jsonTo get view/templates information :
php bin/console debug:twig --format=json, the namespace/path list is in the "loader_path" key.
(None) means no@somethingprefix.@!xxxmeans it is an override directory for the@xxxnamespace (my memory might not be accurate on this one).Doctrine query builder information :
- Get the entities known by doctrine :
php bin/console doctrine:mapping:info --no-ansi - Get the orm name of those entities
- Get the properties of those entities
twig - routes, components, live components maybe :
Answer is in the json of the json of the view/templates informationstranslation :
php bin/console debug:translation en --all --no-ansi
This one might be a bit complicated. « en » is the locale used to get this information. Not all projects will have the english locale.- Get the entities known by doctrine :
@AJenbo I've started an implementation to give you a baseline to make this work.
Unfortunately, I don't know how to code in Rust, so everything has been done using AI.
I've tried to respect the existing codebase, using the Laravel implementation as an example/reference.
The implementation does not run any runtime commands and is in testing on my machine to avoid bugs as much as possible.
Do you have any instructions or recommendations for me before I open the PR?
What's working :
- routes autocomplete
- form option autocomplete
- translation autocomplete
- twig path autocomplete
- service autocomplete
All of this is only working in php files. Are you planning on giving autocomplete in yaml/twig files or is it out of scope ?
For Symfony users some services are defined in yaml files like this :
services: App\BackOffice\Notification\Messaging\AdminNotifierInterface: '@App\BackOffice\Notification\Messaging\NoopAdminNotifier' App\Test\Doctrine\TestConnectionFactory: decorates: 'doctrine.dbal.connection_factory' arguments: [ '@.inner']
Reacted by Anders JenboMy only suggestion would be to use https://github.com/twigstan/twigstan as a reference and a source tests (both projects are MIT licensed)
It looks like @fabpot is working on a LSP / tree-sitter integration for Symfony: https://github.com/symfony/language-tools
The Symfony work is now split into focused pull requests.
Generic foundations used by Symfony
- feat(php): add scalable reference CodeLens #392 — Scalable reference CodeLens
- feat(navigation): navigate PHP symbols in YAML and XML #394 — Navigate PHP symbols in YAML and XML
- feat(php): map transparent proxies to real classes #395 — Map transparent proxies to their real classes
- feat(php): add call hierarchy #413 — PHP call hierarchy, used by the event publisher → event → subscriber flow
Symfony and Doctrine support
- feat(frameworks): add Symfony and Doctrine resource navigation #397 — Symfony and Doctrine resource navigation
- feat(symfony): add service container intelligence #398 — Service container intelligence
- feat(symfony): add route intelligence #399 — Route intelligence
- feat(symfony): add Twig template intelligence #400 — Twig template intelligence
- feat(symfony): add translation intelligence #401 — Translation intelligence
- feat(symfony): add events and Messenger intelligence #402 — Events and Messenger intelligence
- feat(symfony): add ExpressionLanguage intelligence #403 — ExpressionLanguage intelligence
- feat(symfony): add forms, validation, and config schema intelligence #404 — Forms, validation, and configuration schema intelligence
- docs(symfony): add framework playground #405 — Symfony framework playground
- docs(release): correct unreleased Symfony feature notes #406 — Correct the unreleased Symfony feature notes
Shared indexing support
- fix(indexing): canonicalize vendor scan paths #407 — Canonicalize vendor scan paths
- fix(indexing): keep resource startup progress moving #408 — Keep resource startup progress moving
- feat(indexing): add semantic indexing strategy #409 — Add the semantic indexing strategy
The Symfony-specific stack is intended to merge in numerical order from #397 through #406 after the generic foundations. The indexing fixes can be reviewed independently, with #409 following #408. Generic PHP implementation lenses remain isolated in #393 rather than being bundled into the Symfony scope.
Every PR includes a Why section and focused validation.
Reacted by Anders Jenbo, Jiří Velek, Snoweuph, Peep van Puijenbroek and Lukas RakauskasReacted by Jiří Velek, Snoweuph, Lukas Rakauskas and Vjaceslav Longinovnice work! I'll start reviewing it over the next week's, I'm going to try to make 0.11 a short cycle and then start adding features in following releases
Reacted by Jiří Velek, sidux and Lukas RakauskasSince a lot of these stack on top of each other it's helpful if you can rebase them as parts lands. Also the sooner the example project can land the better since that allows it to be tracked as things evolve, bonus points for gradually landing each part as part of the PRs that add the support.
Add support for Symfony - routes, views/templates, doctrine