70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
---
|
|
id: PLN-0104
|
|
ticket: multi-frontend-provider-contract
|
|
title: Introduce FrontendProvider registry API
|
|
status: done
|
|
created: 2026-07-15
|
|
ref_decisions: [DEC-0040]
|
|
tags: [compiler, compiler-general, studio, frontend, registry, multi-frontend]
|
|
---
|
|
|
|
## Briefing
|
|
|
|
DEC-0040 requires common code to resolve frontend behavior through a provider. This plan introduces the API surface in the frontend registry without forcing all consumers to migrate in the same change.
|
|
|
|
Domain owner: `compiler/general`.
|
|
|
|
## Objective
|
|
|
|
Introduce `FrontendProvider` and provider-based registry lookup while preserving existing PBS behavior during migration.
|
|
|
|
## Dependencies
|
|
|
|
- `PLN-0103` should define the normative spec first.
|
|
- Accepted decision: `DEC-0040`.
|
|
- Existing registry module: `prometeu-compiler/prometeu-frontend-registry`.
|
|
|
|
## Scope
|
|
|
|
- Add the `FrontendProvider` contract in the frontend registry module.
|
|
- Add an optional language-service return shape, using an existing interface if one already exists or a minimal neutral placeholder only if required.
|
|
- Add provider registration and provider lookup by `languageId`.
|
|
- Add `require(languageId)` or equivalent explicit lookup that fails clearly for unknown languages.
|
|
- Preserve compatibility methods during migration if existing consumers still call spec or phase lookup.
|
|
|
|
## Non-Goals
|
|
|
|
- Do not register PBS in this plan unless needed for API tests with a simple fixture.
|
|
- Do not migrate build pipeline or Studio consumers in this plan.
|
|
- Do not add plugin discovery, reflection, scanning, external JAR loading, or runtime plugin installation.
|
|
- Do not define a broad editor API.
|
|
|
|
## Execution Method
|
|
|
|
1. Inspect `FrontendRegistryService`, `FrontendSpec`, and `FrontendPhaseService` to confirm current method names and package ownership.
|
|
2. Add `FrontendProvider` to the registry-facing package with `specification()`, `compiler()`, and optional `languageService()`.
|
|
3. Update `FrontendRegistryService` so its primary storage is provider keyed by `languageId`.
|
|
4. Add `require(languageId)` or the nearest local naming equivalent for provider lookup.
|
|
5. Keep old spec/phase accessor methods as provider-derived compatibility wrappers if they are still used.
|
|
6. Add registry unit tests for provider registration, provider lookup, duplicate language handling if currently supported, and unknown-language errors.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- `FrontendProvider` exists and exposes all responsibilities required by `DEC-0040`.
|
|
- `FrontendRegistryService` can resolve a provider by `languageId`.
|
|
- Unknown `languageId` lookup fails with a clear exception or diagnostic message.
|
|
- Existing callers can still compile until their migration plan runs.
|
|
|
|
## Tests
|
|
|
|
- Registry test: registered provider is returned by `languageId`.
|
|
- Registry test: unknown `languageId` fails clearly.
|
|
- Registry test: provider-derived spec listing remains correct if compatibility methods remain.
|
|
- Run the relevant Gradle test task for `prometeu-frontend-registry`.
|
|
|
|
## Affected Artifacts
|
|
|
|
- `prometeu-compiler/prometeu-frontend-registry/src/main/java/p/studio/compiler/FrontendRegistryService.java`
|
|
- New `FrontendProvider` contract in the same registry API surface.
|
|
- Registry tests under `prometeu-compiler/prometeu-frontend-registry/src/test/...`
|