Background

Currently, preferences are exclusively a frontend concept in Theia, with the PreferenceService only available in the browser module. This design aligns with Theia's workspace-specific preferences architecture, where workspaces themselves are a frontend concept.

The current recommendation for backend functionality that depends on preferences is to pass preference values as parameters from the frontend to the backend service. While this approach works well for most use cases, it presents challenges in some scenarios:

• Headless operations where no frontend is available
• Backend startup customization that must occur before frontend initialization
• Theia based applications not leveraging the workspace concept, for whom this architecture requires additional effort

Some adopters currently work around these limitations by directly parsing/modifying their preference persistence (e.g. ~/.theia/settings.json), but this approach is problematic as it only contains modified values and doesn't provide access to default values and schemas.

Feature Suggestion:

• Expose a backend-compatible PreferenceService that provides at minimum the USER scope
• Modify the preference schema contribution pattern to allow schemas to be provided in the backend
• Maintain alignment with the existing preference architecture