Ezie Ls Laravel Package

Getting Started

First, calibrate expectations: ezsystems/ezie-ls is not a Laravel package. It is the language-server half of the long-abandoned eZ Publish IDE extension (ezie), aimed at the eZ Publish 4/5 legacy template dialect (.tpl files with {*} comments, {def}, {fetch}, {attribute}, etc.). There is nothing here that hooks into the container, Eloquent, Artisan, or Blade. You would only reach for it if you have inherited a legacy eZ Publish site alongside your Laravel work and want editor intelligence for its templates.

Minimal steps:

1. Read the repository README and composer.json first — the platform constraints there are the real gate. The last tagged release is May 2014, so expect PHP 5.4–5.6 era syntax and dependency pins.
2. Do not try to install it into a modern Laravel app's composer.json. Install it in isolation: a dedicated PHP 5.6 container, a tools/ directory with its own composer.json, or a global Composer home inside a VM.
3. Let Composer resolve, then locate the server entry point (typically a bin/ script or a console command registered by the package). Run it with --help to discover the transport flag and any --root/workspace argument.
4. Wire your editor to that command as a language server, scoped to your eZ Publish project root only.

First use case: open a single .tpl file from an eZ Publish design/extension directory, confirm you get completion on template operators and fetch function names, and that diagnostics flag unknown operators. That round-trip tells you whether the server is functional before you invest in workspace-wide indexing.

Implementation Patterns

Isolated toolchain, not application dependency. Treat this like a global CLI tool. Keep it out of require/require-dev in any Laravel composer.json; version conflicts with modern Symfony/PSR packages are near-certain. A docker/tools/ezie/Dockerfile pinned to php:5.6-cli plus a bind-mounted source tree is the lowest-friction pattern.

Editor-as-client wiring. The server only speaks a protocol; the value comes from the client. Configure your editor's generic LSP client to launch the binary with the eZ Publish installation root as the workspace, and restrict the file associations to *.tpl so it never touches .php or .blade.php files in the same monorepo.

Pair it with a real PHP language server. Run Intelephense/phpactor for your Laravel code and this server only for the legacy template subtree. They solve disjoint problems; don't try to make one cover both.

Legacy-bridge projects. If you're building a Laravel front end against an eZ Publish content repository (via REST or a DB view), keep the eZ tree in a sibling directory and index it separately. The server's understanding of template includes is relative to the eZ design layout, so mirroring that layout is what makes go-to-definition on {include} useful.

Use it as a reference architecture. The genuinely transferable pattern for a Laravel developer is the shape of the thing: parse a non-PHP template language into an AST, run diagnostics, publish to an LSP client, index a workspace. If you've ever wanted Blade-aware completion (@include targets, component props, Livewire actions), this codebase — small, PHP-native, archived — is a compact study of that pipeline without the Symfony/Laravel scaffolding of modern alternatives.

CI: keep it off the critical path. Never gate a Laravel pipeline on this. If you want template linting, run it in an optional, non-blocking job and treat failures as advisory.

Gotchas and Tips

• Archived means zero support. No security patches, no PHP 8 compatibility work. Never expose the process to untrusted workspaces or network transports; run it locally, on trusted source only.
• Composer will refuse to install on modern PHP. Plan for --ignore-platform-reqs in a container, but expect runtime fatals rather than Composer errors — those are the ones that actually block you.
• Protocol drift. A 2014-era server predates the stabilized LSP specification. Modern clients may negotiate features it never implemented; expect missing capabilities silently rather than failures. Prefer a client that lets you disable unsupported features.
• Workspace root matters. Include resolution and fetch target discovery depend on the root you pass. Pointing it at a subdirectory silently degrades to "operators only" completion — a common cause of "it half works."
• Index staleness. Long-running server processes cache parsed templates. After pulling changes, restart the server; there is no reliable file-watcher to depend on.
• Memory growth. PHP long-running processes without careful refcounting leak. Restart periodically, especially in large designs with deep include graphs.
• Twig is out of scope. eZ Platform moved to Twig; this server understands the legacy .tpl dialect only. If your project is eZ Platform/Twig, this package will be actively misleading.
• Not Blade-aware in any way. Don't expect it to help with Laravel templates, @directives, or component resolution.
• Extension point is the source, not config. There is no meaningful plugin API you can rely on. Anything you need — new operators, custom fetch functions, extra diagnostics — means forking the repo. If you fork, vendor it into your own tools/ namespace and pin the commit, because upstream will never move.
• Documentation is thin and dated. The README and the code are the only reliable references; blog posts and editor-plugin instructions from that era assume editor versions that no longer exist.