Add effect-language-service

[rvaccone]

Describe your changes

Adds ⁠effect-language-service, a TypeScript language service plugin that provides enhanced diagnostics, refactors, and code actions for Effect-TS projects.

This package is a TypeScript plugin designed to be loaded with ⁠typescript-language-server, not a standalone LSP server. While the official documentation recommends per-project installation with npm, this PR enables global installation with Mason and manual configuration in ⁠vim.lsp.config. If this doesn't fit mason-registry's scope, I understand.

Evidence on requirement fulfillment (new packages only)

The repository has 316 stars on GitHub at the time of this PR.

Checklist before requesting a review

• If the package is available at nvim-lspconfig, I also added the respective name to neovim.lspconfig.

N/A: This is a TypeScript plugin, not a standalone LSP server

• I have successfully tested installation of the package.
• I have successfully tested the package after installation.

Screenshots

Testing details

• Successfully installed via ⁠:MasonInstall effect-language-service
• Configured in ⁠vim.lsp.config with ⁠init_options.plugins.location pointing to Mason installation
• Confirmed Effect diagnostics appear (e.g., "Effect must be yielded or assigned to a variable")
• Tested in a project WITHOUT ⁠@effect/language-service in ⁠node_modules to verify Mason installation works

Example configuration

vim.lsp.config("ts_ls", {
  init_options = {
    plugins = {
      {
        name = "@effect/language-service",
        location = vim.fn.stdpath("data") 
          .. "/mason/packages/effect-language-service/node_modules/@effect/language-service",
      },
    },
  },
})

[chrisgrieser]

I am somewhat hesitant about adding plugins for packages to the registry, since that increases the number of potential packages by a lot, making the registry potentially much harder to maintain.

@other maintainers Any thoughts?

[williamboman]

Yeah unfortunately packages does not support installation of "subpackage" dependencies like these. Providing them as standalone packages doesn't make sense to me imo. I managed to come pretty far with subpackage support but the implementation was not a good fit for general usage.

My understanding of TS plugins specifically is that they're recommended to be installed locally anyways. Does typescript-language-server not automatically pick up plugins configured in tsconfig.json, for example per their docs?

[rvaccone]

typescript-language-server does automatically pick up plugins configured in ⁠tsconfig.json, but only when they're installed in the project's local ⁠node_modules.

The reason for this PR is to avoid per-project installations. With the Mason global installation approach, the plugin isn't in the project's node_modules, so automatic detection doesn't work. That's why the manual ⁠init_options.plugins.location configuration is necessary.

I understand the concern about subpackage dependencies. My use case was for personal convenience, and I debated whether to submit this PR given the extra configuration needed. If this doesn't align with mason-registry's architecture or maintenance goals, I completely understand and am happy to close the PR.