bQUARKz
35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
79 lines
2.8 KiB
Markdown
79 lines
2.8 KiB
Markdown
---
|
|
id: AGD-0058
|
|
ticket: multi-frontend-compiler-vs-language-services
|
|
title: Separar compilacao de servicos editoriais de frontend
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [compiler, compiler-general, studio, lsp, editor, frontend, multi-frontend]
|
|
---
|
|
|
|
# Agenda - Separar compilacao de servicos editoriais
|
|
|
|
## Objetivo
|
|
|
|
Domain owner: `compiler/general`, com impacto em `studio/lsp`.
|
|
|
|
Separar o contrato necessario para build do contrato necessario para IDE, permitindo frontends progressivos: compilacao, diagnostics/highlighting e experiencia editorial completa.
|
|
|
|
## Contexto atual
|
|
|
|
O PBS fornece compilacao e varias superficies editoriais. Historicamente o Studio e o LSP podem assumir que semantic tokens, diagnostics e navegação vêm do mesmo servico PBS.
|
|
|
|
## Escopo
|
|
|
|
- Identificar interfaces atuais de compilacao e editor.
|
|
- Definir capabilities opcionais para servicos editoriais.
|
|
- Garantir que ausencia de completion, hover, definition ou semantic tokens nao invalide um frontend compilavel.
|
|
|
|
## Fora de escopo
|
|
|
|
- Implementar novas features editoriais.
|
|
- Redesenhar todo o LSP.
|
|
- Criar frontend real sem recursos editoriais.
|
|
|
|
## Arquivos e componentes a inspecionar
|
|
|
|
- `prometeu-lsp/prometeu-lsp-api/...`
|
|
- `prometeu-lsp/...`
|
|
- `prometeu-studio/src/main/java/p/studio/...editor...`
|
|
- `prometeu-compiler/frontends/prometeu-frontend-pbs/...`
|
|
- `prometeu-compiler/prometeu-build-pipeline/...`
|
|
|
|
## Alteracoes propostas
|
|
|
|
Opcao A: `FrontendProvider` entrega `FrontendCompiler` obrigatorio e `Optional<FrontendLanguageService>`.
|
|
|
|
Opcao B: dividir language service em interfaces menores, como diagnostics, completion, hover, definition e semantic tokens.
|
|
|
|
Recomendacao inicial: mapear primeiro os consumidores. Se o LSP ja resolve features separadamente, usar interfaces menores; caso contrario, um language service opcional com capabilities pode ser suficiente.
|
|
|
|
## Estrategia de implementacao
|
|
|
|
Caracterizar o comportamento PBS atual, definir fallback para recurso ausente e migrar chamadas editoriais para consulta de capability antes de invocar servico.
|
|
|
|
## Testes necessarios
|
|
|
|
- Frontend provider compilavel sem language service nao quebra build.
|
|
- LSP/Studio tratam feature ausente como resposta vazia ou unsupported documentado.
|
|
- PBS continua expondo as mesmas respostas editoriais.
|
|
|
|
## Criterios de aceitacao
|
|
|
|
- Compilacao nao depende de APIs de IDE.
|
|
- Recursos editoriais ausentes sao opcionais.
|
|
- O contrato permite os niveis 1, 2 e 3 descritos no alinhamento.
|
|
|
|
## Riscos
|
|
|
|
- Introduzir `Optional` em excesso sem uma politica consistente de fallback.
|
|
- Acoplar diagnostics de build e diagnostics editoriais sem separar latencia e escopo.
|
|
|
|
## Decisoes que devem ser registradas
|
|
|
|
- Granularidade final das interfaces editoriais.
|
|
- Comportamento padrao para capability ausente.
|
|
- Relacao entre diagnostics de compilacao e diagnostics de editor.
|
|
|