Add Gitlab Duo LSP configuration

[tachyons]

Add GitLab Duo Language Server configuration

Summary

This PR adds support for the GitLab Duo Language Server, enabling AI-powered code suggestions through the Language Server Protocol.

What is GitLab Duo?

GitLab Duo is GitLab's AI-powered coding assistant that provides intelligent code completion and suggestions directly in your editor. The LSP implementation allows any LSP-compatible editor to integrate with GitLab Duo.

Key Features

• OAuth Device Flow Authentication: Secure authentication using GitLab's OAuth device flow
• Automatic Token Refresh: Handles token expiration and refresh automatically
• Inline Code Completion: Native support for Neovim's inline completion API (requires Neovim 0.12+)
• Multi-language Support: Works with 25+ programming languages including Python, JavaScript, TypeScript, Go, Rust, and more
• User Commands: Convenient commands for authentication management:
  • :LspGitLabDuoSignIn - Authenticate with GitLab
  • :LspGitLabDuoSignOut - Sign out and remove tokens
  • :LspGitLabDuoStatus - View authentication status

Prerequisites

• Node.js and npm installed
• GitLab account with Duo Pro license
• Neovim 0.12+ (for inline completion support)

Current Limitations

This initial implementation only supports GitLab.com. Support for self-managed GitLab instances will be added in a future iteration. The configuration is structured to make this addition straightforward when the OAuth application setup is documented for self-managed instances.

Usage

Basic Setup

vim.lsp.enable("gitlab_duo")

Enable Inline Completion

Add this to your config to enable inline completions with Tab acceptance:

vim.api.nvim_create_autocmd('LspAttach', {
  callback = function(args)
    local client = vim.lsp.get_client_by_id(args.data.client_id)
    
    if vim.lsp.inline_completion then
      vim.lsp.inline_completion.enable(true, { bufnr = args.buf })
      
      -- Tab to accept
      vim.keymap.set('i', '<Tab>', function()
        if vim.lsp.inline_completion.is_visible() then
          return vim.lsp.inline_completion.accept()
        else
          return '<Tab>'
        end
      end, { expr = true, buffer = args.buf })
    end
  end
})

Authentication Flow

1. Run :LspGitLabDuoSignIn in any buffer with the LSP attached
2. Your browser will open to GitLab's authorization page
3. Authorize the application
4. The LSP will automatically authenticate and start providing suggestions

Tokens are stored locally and refreshed automatically.

Implementation Details

• Uses npx to run the GitLab LSP package from GitLab's npm registry
• Implements OAuth device flow for secure authentication
• Token storage in Neovim's data directory
• Automatic token refresh with 60-second expiration buffer
• Error handling for token validation and feature state changes
• Telemetry disabled by default
• Hardcoded to gitlab.com in this iteration

Testing

Tested on:

• Neovim v0.12+
• Multiple file types (Lua, Python, JavaScript, TypeScript, Go, Rust)
• Token refresh flow
• Authentication error handling

Future Enhancements

• Support for self-managed GitLab instances with custom URLs
• Configurable OAuth client credentials for self-managed setups

Related Links

• GitLab LSP Repository
• GitLab Duo Documentation

[justinmk]

Just mentioning: users can provide arbitrary fields using vim.lsp.config():

vim.lsp.config('gitlab_duo', {
  gitlab_duo = {
    gitlab_url = '...',
  },
})

Then in callbacks such as cmd() in this config, which are passed a config object, you can access those fields:

cmd = function(..., config)
  local foo = config.gitlab_duo
  ...
end)

[tachyons]

@justinmk I couldn't get this working, cmd expects a table, not a function, right ?

[justinmk]

cmd can be a function. Example

nvim-lspconfig/lsp/leanls.lua

Lines 16 to 19 in cbd1e91

	cmd = function(dispatchers, config)
	local local_cmd = { 'lake', 'serve', '--', config.root_dir }
	return vim.lsp.rpc.start(local_cmd, dispatchers)
	end,

[tachyons]

@justinmk Thanks, cmd does not requires gitlab_uri, it is required in the workspace/didChangeConfiguration call. I couldn't find an easy way to pass this value around, we also need to make client_id configurable for self managed GitLab instances as the client_id will also be different. So I thought doing it in a separate iteration.

[justinmk]

I couldn't find an easy way to pass this value around

You can set arbitrary properties on the client or config.

[justinmk]

maybe a code comment that gives a reference about where this id came from. e.g. is it a personally generated thing or part of official gitlab docs.

[justinmk]

This is a lot of code which is normally discouraged in this repo, but it looks pretty good and points to some common use-cases that we need to start thinking about in the stdlib. And for supporting LSP/AI providers that require sign-in, it's good to have self-contained examples (another is copilot.lua) of what is required to complete that full process.

So I'm fine with this.

[justinmk]

That seems kind of strange. Do users need to generate their own client_id? Is this config dependent on your account?

[tachyons]

@justinmk There is no need to create a client_id per user. Alternatively one of the maintainer of this repo can create a GitLab application and add the client_id here.

[justinmk]

Makes no difference to me, just trying to understand, and ensure that we document stuff and can answer questions in the future.

[justinmk]

I should have asked this for Copilot too, but ... why don't we just do this when this config is enabled? Why should the user need to manually add this.

[tachyons]

@justinmk I used copilot.lua as the reference implication, that is why I followed the same pattern

[justinmk]

I think we should change both imo