Skip to content

Support extension contributions for third-party validator extensions #110

Description

@esmasth

Problem

The YANG Language Server supports loading custom IValidatorExtension implementations via extension.validators in yang.settings. However, this mechanism has limitations when used with VS Code:

  1. Settings override problem: Project-level yang.settings overrides (not merges with) user-level settings. If a user configures validators in ~/.yang/yang.settings but a project has its own yang.settings for other purposes (e.g., excludePath), the validators are silently lost.

  2. No extension-to-extension integration: Third-party VS Code extensions that ship custom validators have no way to register them with the YANG language server. Users must manually configure extension.classpath and extension.validators in every project.

Proposal

Add an extension contribution API so that other VS Code extensions can declaratively register validator jars and classes. The host extension (yang-vscode) would:

  1. Scan installed extensions for a namespaced key (e.g., "typefox.yang-vscode") in their package.json
  2. Add declared jars to the server's classpath via an environment variable (YANG_EXTRA_CLASSPATH)
  3. Pass declared validator class names to the server via a system property (-Dyang.extra.validators)

Contributor extension package.json example

{
    "extensionDependencies": ["typefox.yang-vscode"],
    "typefox.yang-vscode": {
        "extensions": [
            {
                "jar": "lib/my-validators.jar",
                "validators": [
                    "com.example.MyCustomValidator"
                ]
            }
        ]
    }
}

Server-side changes needed (yang-lsp)

  • Launch scripts need to support appending to the classpath via YANG_EXTRA_CLASSPATH env var
  • The server launcher needs to read -Dyang.extra.validators and add them to constantSettings
  • extension.validators should merge across settings levels instead of override (so validators from constantSettings, user, workspace, and project levels are all loaded)

This would enable a clean ecosystem where third-party extensions can ship custom YANG validators without requiring manual user configuration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions