Idea Title
Fluid Developer Experience
What is my idea about?
With this community budget idea, I want to advance the developer experience (DX) for Fluid templating with three consecutive projects.
Components Autocomplete
For IDEs that can work with XSD files (like PHPStorm), we already have pretty good autocompletion: Fluid generates XSD files for all available ViewHelpers, and since TYPO3 13 this is even built-in via the “fluid:schema:generate” console command. However, a missing puzzle piece is autocompletion for Fluid components, which requires a few more tweaks within Fluid. In the end, this will work just like ViewHelpers.
VSCode Extension
On VSCode-based editors, the tooling situation for Fluid is currently worse. There are a few VSCode extensions available, which provide either basic syntax highlighting or some variant of autocompletion (or both). However, there has never been a de facto standard VSCode extension for Fluid. From my experience, the lack of proper and official tooling is a major showstopper for frontend developers that come from the modern JavaScript ecosystem. Good developer experience should be part of our product, so we need an “official” Fluid VSCode extension. This will allow us to focus our collective efforts on one project.
In my opinion, there are a few cornerstones for this extension:
- available in relevant extension registries
- compatible with relevant VSCode-based editors (e. g. Cursor)
- autocompletion generated from PHP source code
- straightforward setup process
- open to contributions
- marketing/communication in official channels
Language Server
While an official VSCode extension is a step in the right direction, it will only bring us so far: Medium to long term, Fluid needs a language server.
Language servers are processes that run independently of the IDE/editor and provide relevant information for syntax highlighting, autocompletion and more advanced features. One language server implementation can also cover multiple IDEs/editors (PHPStorm, VSCode, neovim, …), which would make maintenance a lot easier.
The problem with a Fluid language server is that the Fluid parser in its current state cannot be used for that purpose: It hasn’t been designed to keep track of the original template code. Incidentally, this is also the reason why some of Fluid’s exceptions are too generic and cannot refer to the original template file, line and character.
There are multiple approaches to tackle this:
- extend the current parser
- rewrite/replace the current parser
- build a separate parser just for IDE support
… and within each option, there are several sub options that need to be explored. As a first step, this needs to be researched, discussed and tested. This process will result in some kind of document and maybe also a few prototypes, which can be used for follow-up projects to make more informed decisions.
What do you want to achieve by 30th of April 2026?
- Autocomplete for Fluid components in PHPStorm
- Official Fluid extension for VSCode, submitted to relevant extension registries
- Research for Fluid language server
What is the potential impact of your idea for the overall goal?
Improved developer experience for Fluid templates, easier onboarding of frontend developers
How does your Idea align with the strategic goals for TYPO3 v14.
Improved developer support for Fluid reduces complexity in daily work (Strategic Goal 2), can ease long-term maintenance (Strategic Goal 8) and might also improve interconnectivity (Strategic Goal 7), in the sense that developers from other areas that want to integrate with TYPO3 have an easier onboarding experience.
Which budget do we need for this idea?
10000 Euro
My Name
Simon Praetorius