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:
-
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.
-
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:
- Scan installed extensions for a namespaced key (e.g.,
"typefox.yang-vscode") in their package.json
- Add declared jars to the server's classpath via an environment variable (
YANG_EXTRA_CLASSPATH)
- 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.
Problem
The YANG Language Server supports loading custom
IValidatorExtensionimplementations viaextension.validatorsinyang.settings. However, this mechanism has limitations when used with VS Code:Settings override problem: Project-level
yang.settingsoverrides (not merges with) user-level settings. If a user configures validators in~/.yang/yang.settingsbut a project has its ownyang.settingsfor other purposes (e.g.,excludePath), the validators are silently lost.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.classpathandextension.validatorsin 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:
"typefox.yang-vscode") in theirpackage.jsonYANG_EXTRA_CLASSPATH)-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)
YANG_EXTRA_CLASSPATHenv var-Dyang.extra.validatorsand add them toconstantSettingsextension.validatorsshould merge across settings levels instead of override (so validators fromconstantSettings, 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.