Extending lspconfig's default configs should be reflected in mason-lspconfig's mapping

[bnwa]

I'm testing adding a LSP package for Fish shell to Mason in a local registry. I can properly register the local registry, install the LSP package, and evoke the LSP directly via vim.lsp.start. The trouble comes when trying to evoke the installed LSP through the layers of nvim-lspconfig in concert with mason-lspconfig.

Since nvim-lspconfig.configs does not feature this LSP server, one must extend that object so that the _newindex metamethod therein picks it up. However, mason-lspconfig.mapping.servers is a static list. So attempting to add a handler for this new LSP to mason-lspconfig results in a predictable mason-lspconfig.setup_handlers: Received handler for unknown lspconfig server name: fish-language-server.

I understand the workaround is to iterate the the installed server names that have a mapping in mason-lspconfig.mapping.servers however I think it may be an improvement to dynamically generate the server mapping from the maintained static mapping, so that servers added to nivm-lspconfig.configs via extension are registered with their given key and identical value. So in this case, I would expect to populate mapping.servers with, e.g. ['fish-language-server'] = 'fish-language'server'.

Is there something I may be missing if this is assessment is inaccurate?

[bnwa]

This is actually a feature request in mason-lspconfig