Deprecate "initializationOptions" in favor of "initialization_options"

[jwortmann]

Use the snake case convention for settings in *.sublime-settings files, and make it consistent with all other configuration keys in the Client Configuration.

This change should be fully backwards compatible with the old "initializationOptions", both for shipped settings in helper packages, and also for user overrides.

Ideally we should check which helper packages uses "initializationOptions" and update those, as well as the sublime-package.json schema files.

[netlify]

✅ Deploy Preview for sublime-lsp ready!

Name	Link
🔨 Latest commit	15ecd43
🔍 Latest deploy log	https://app.netlify.com/projects/sublime-lsp/deploys/699f6b54dd29c80007e9f52a
😎 Deploy Preview	https://deploy-preview-2779--sublime-lsp.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[rchl]

Ideally we should check which helper packages uses "initializationOptions" and update those, as well as the sublime-package.json schema files.

That's gonna be quite some job:

LSP-anakin/LSP-anakin.sublime-settings
LSP-angular/LSP-angular.sublime-settings
LSP-angular/sublime-package.json
LSP-astro/LSP-astro.sublime-settings
LSP-astro/sublime-package.json
LSP-clangd/LSP-clangd.sublime-settings
LSP-clangd/sublime-package.json
LSP-cmake/LSP-cmake.sublime-settings
LSP-copilot/sublime-package.json
LSP-css/LSP-css.sublime-settings
LSP-css/sublime-package.json
LSP-Dart/LSP-Dart.sublime-settings
LSP-elixir/LSP-elixir.sublime-settings
LSP-elm/LSP-elm.sublime-settings
LSP-elm/sublime-package.json
LSP-esphome/LSP-esphome.sublime-settings
LSP-esphome/sublime-package.json
LSP-gopls/scripts/update-schema-settings.py
LSP-gopls/sublime-package.json
LSP-Grammarly/LSP-Grammarly.sublime-settings
LSP-html/LSP-html.sublime-settings
LSP-html/sublime-package.json
LSP-intelephense/LSP-intelephense.sublime-settings
LSP-intelephense/sublime-package.json
LSP-jdtls/LSP-jdtls.sublime-settings
LSP-json/LSP-json.sublime-settings
LSP-json/sublime-package.json
LSP-julia/LSP-julia.sublime-settings
LSP-julia/sublime-package.json
LSP-lean/LSP-lean.sublime-settings
LSP-lua/LSP-lua.sublime-settings
LSP-marksman/LSP-marksman.sublime-settings
LSP-marksman/sublime-package.json
LSP-metals/LSP-metals.sublime-settings
LSP-PowerShellEditorServices/LSP-PowerShellEditorServices.sublime-settings
LSP-prisma/LSP-prisma.sublime-settings
LSP-R/LSP-R.sublime-settings
LSP-relay/sublime-package.json
LSP-ruff/LSP-ruff.sublime-settings
LSP-ruff/sublime-package.json
LSP-svelte/LSP-svelte.sublime-settings
LSP-terraform/LSP-terraform.sublime-settings
LSP-terraform/sublime-package.json
LSP-TexLab/LSP-TexLab.sublime-settings
LSP-Tinymist/sublime-package.json
LSP-ty/LSP-ty.sublime-settings
LSP-ty/sublime-package.json
LSP-typescript/LSP-typescript.sublime-settings
LSP-typescript/sublime-package.json
LSP-volar/LSP-volar.sublime-settings
LSP-volar/sublime-package.json
LSP-vtsls/LSP-typescript.sublime-settings
LSP-vtsls/sublime-package.json

Though I think I have a script somewhere that checks out each lsp package, applies chosen modification and creates PR automatically.

[jwortmann]

I noticed that many packages reference the LSP-plugin-base schema ID in the sublime-package.json files. I wasn't aware that it is possible to add more specific schema definitions for the "initialization_options" and/or "settings" objects on top of that via

"allOf": [
  {
    "$ref": "sublime://settings/LSP-plugin-base"
  },
  {
    "properties": {
      "initialization_options": {
        // ...
      },
      "settings": {
        // ...
      }
    }
  }
]

but apparently that works fine, and I updated the schemas files accordingly in the packages that were created by me. Ideally all helper packages should reference LSP-plugin-base in their schema files. Then, if they don't actually use "initializationOptions", this change and any similar future modifications to the base schema get automatically propagated to the helper packages.

And for packages which currently do use "initializationOptions", this change should still consist of only one or two lines that needs to be updated by a simple word replacement. Even better if it's possible to automate that with the script you mentioned.

[rchl]

You want to create a definition for plugin settings (by convention called PluginConfig) and reference it also from project settings. Look at https://github.com/sublimelsp/LSP-eslint/blob/main/sublime-package.json for example.

[predragnikolic]

I was just casually going through the code, noticed one spot

LSP/plugin/tooling.py

Line 367 in 42ff4ee

line(' - init_options')

init_options label is displayed when we run lsp: troubleshoot server - would be nice to rename it initialization_options