TYPO3 specific LSP implementations: Fluid (2. Round 2026)

TYPO3 Association Community Budget Ideas 2026 Round Two
1

by @teddytrombone

What is my idea about?

Code-/Autocompletion/Intellisense for Fluid tags is only possible in IDEs which support XSD based autocompletion for HTML (and not only XML) and only for tag syntax, not for shorthand syntax. With a language server we could have autocompletion and other LSP functionality in all IDEs which support LSP. And not only in HTML but also other template formats and for shorthand syntax.

In addition there are various other parts that are specific to TYPO3 which could benefit from additional LSP support (see goals for further examples).

What must be achieve by 31st of August 2026?

The LSP will be implemented as TYPO3 extension which provides a console command. With this console command IDEs are able to connect to a specific TYPO3 installation. As there are many features in TYPO3 which are evaluated at runtime, an extension can get all needed informations of a TYPO3 installation which couldn’t be determined by a standalone tool.

The goals to be achieved by the end of August - aka the first version - will be:

General:

  • Basis for LSP implementation for TYPO3 13 LTS and 14 LTS (maybe 12 LTS as well - TBD)
  • “Extension points” to provide LSP functionality for different TYPO3 features. Via those “extension points” extension developers can also provide additional information to the LSP extension or even provide LSP functionality for own DSLs.
  • Implementation LSP functionality for Fluid
  • VS Code extension to connect to the LSP
  • Neovim sample configuration to connect to the LSP

Fluid LSP functionality:

  • LSP features will work independent from the template format (not only inside HTML)
  • Code completion for ViewHelpers for tag and shorthand syntax of all ViewHelpers of all installed extensions (not only TYPO3 sysexts but also e.g. “vhs” or “news” if they are installed). Completion will provide namespaces (also merged namespaces), ViewHelpers of this namespace, arguments of the ViewHelper.
  • Hover information for tags/shorthand syntax per ViewHelper
  • “Goto defintion” for tags/shorthand syntax (IDE opens the PHP file of the ViewHelper)
  • Basic diagnostic information based on the default Fluid parser of the TYPO3 installation
  • Code completion for default template preprocessors shipped with TYPO3/Typo3Fluid (allthough there will be various extension points to support LSP features for individual template preprocessors for extension developers)
  • ViewHelper specific extensions; examples:
    • extensionName argument of <f:translate /> will provide completion for all extension names; id/key parameter will provide all ids of the locallang.xlf of this extension
    • typoscriptObjectPath argument of <f:cObject /> will provide all configured cObjects
    • name argument of <f:layout /> will provide completion of all available layouts for this template and “goto definition” will jump to the layout file
    • section argument of <f:render /> will provide completion for all sections of a partials/template and “goto definition” will jump to the section inside the correct file
    • ViewHelper specific implementations can be added by extension developers through defined extension points (in addition to the out-of-the-box functionality for all available ViewHelpers regardless of the extension)

General LSP functionality:

  • Code completion and file linking of “EXT:” paths in most file types (means: not only Fluid, but also in TypoScript files, PHP files etc. as long as these are “complete” parts - no variables or constants!)
  • Code completion and file linking of “LLL:EXT:” paths
  • Code completion, hover support and “goto definition” for LLL paths containing XLF ids (e.g. hovering over CType.textmedia of LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:CType.textmedia will show “Text & Media”)
  • Maybe part of the first version: Completion of PHP classes for usage inside (not only) TypoScript or YAML files
  • Unit Tests​:face_exhaling:

Some ideas for the project after August:

  • LSP functionality for TypoScript like completion, syntax highlighting etc.
  • New tolerant Fluid parser to get
    • better diagnostics (functionality with current Typo3Fluid implementation is limited for use in LSPs)
    • Code actions like transforming tag syntax to shorthand syntax and vice versa
  • LSP functionality inside yaml files like form definitions

What is the potential impact of your idea for the overall goal?

Developers can have code completion, hover support, “goto definition” and other LSP features in (not only) Fluid templates. The speed of developing in TYPO3 can be increased.

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.

Budget for this idea?
10.000 Euro

My Name
Manfred Egger

1 Like
2

This idea:

might work well together with my content model suggestion and Fluid Components. A Fluid Component could have a TextMediaContentElement (content model) as its argument. The LSP could then deliver autocompletion for the available properties. It would be great to work on this together.

1 Like
3

@teddytrombone Maybe you have seen the current initiative about Fluid DX, which has some overlap with what you’re planning here. To be clear: I certainly don’t oppose what you’re planning here, but it probably makes sense that we talk if your idea would be accepted. For example, I’ll be releasing an official VSCode extension for Fluid soon (without a LSP), so it might make sense to integrate your LSP setup into that extension rather than creating yet another project.

Feel free to contact me about that, e. g. via Slack or email.

1 Like