TYPO3 specific LSP implementations: Fluid

by Manfred egger

What is your 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 tags 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 shorthand syntax.
In addition there are various other parts that are specific to TYPO3 could benefit from additional LSP support (see goals for further examples).

What do you want to achieve by the end of Q2 2024?

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 Q2 - aka the first version - will be:

General:

  • Basis for LSP implementation based on phpactor/language-server for TYPO3 11 LTS and 12 LTS
  • “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 features will work independent from the template format (not only inside HTML)
  • Code completion for ViewHelpers for tags 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 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 events (in addition to the out-of-the-box functionality for all available ViewHelpers regardless of the extension)

General:

  • 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 they 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 Q2:

  • Supporting TYPO3 13 LTS
  • LSP functionality for TypoScript like completion, syntax highlighting etc.
  • New 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
  • 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.

Which budget do you need for your idea?

10.000 Euro

4 Likes

10,000 Euro are a lot of money. What are the long term plans for the maintenance of this extension for version 13 and beyond as there might not be more funding available by the TYPO3 Association?

I do plan to update the extension as long as it has any use for me in my daily work.
The outlined features “after Q2” are planned to be developed in any case allthough it might help if there is some funding :grin:

Parts of it are already covered by the PhpStorm Plugin https://plugins.jetbrains.com/plugin/11151-typo3-fluid--enterprise
Coding something from scratch will be very challenging and then also market it in the TYPO3 communit that it is also used afterwards so that the investment was not just for a hand full of people but for “the community”.

1 Like

You are right, this plugin covers parts of my idea but as you said it’s only for PhpStorm/JetBrains IDEs. A LSP based solution is independent from the IDE so anybody with an IDE with LSP support can use this. Also PhpStorm seems to have LSP support but I don’t know if there are additional requirements to get this running.
Regarding the “community” argument: I guess this is valid for all community budget ideas which will not be part of TYPO3 core so imho this is not specific to my idea.

I think this is what’s the poll is all about: let the community decide if the idea has enough use for “the community” :grinning:

We use VSCode and would find this very useful. In fact, we were considering pitching something similar for a future quarter, but it looks like you have done much more research into it, so I’m delighted to see this proposal.