{"id":14929,"library":"sql-language-server","title":"SQL Language Server","description":"sql-language-server is an implementation of the Language Server Protocol (LSP) providing intelligent features for various SQL dialects, including linting, autocompletion, and schema introspection. It is designed to be run as a standalone server process, enabling integration with code editors and IDEs (like VS Code) that support LSP. The current stable version is 1.7.1, with minor releases appearing to follow a monthly or bi-monthly cadence, indicating active development. Key differentiators include its pluggable architecture for different SQL database clients (e.g., PostgreSQL, SQLite, BigQuery) and its focus on robust parsing and error handling, making it a valuable tool for SQL development workflows. It ships with TypeScript types, facilitating its use in TypeScript-based environments.","status":"active","version":"1.7.1","language":"javascript","source_language":"en","source_url":"https://github.com/joe-re/sql-language-server","tags":["javascript","sql","language-server","language-server-protocol","lint","autocompletion","typescript"],"install":[{"cmd":"npm install sql-language-server","lang":"bash","label":"npm"},{"cmd":"yarn add sql-language-server","lang":"bash","label":"yarn"},{"cmd":"pnpm add sql-language-server","lang":"bash","label":"pnpm"}],"dependencies":[{"reason":"Core dependency for implementing the Language Server Protocol.","package":"vscode-languageserver","optional":false},{"reason":"Used for connecting to PostgreSQL databases for schema introspection and completion. Optional if not using PostgreSQL.","package":"pg-client","optional":true},{"reason":"Used for connecting to SQLite databases for schema introspection and completion. Optional if not using SQLite.","package":"sqlite3","optional":true}],"imports":[{"note":"Primarily an executable server. This type defines configuration options sent from the client to the server and is used for type checking client-side configurations. Direct programmatic import of server logic is not the primary use case.","symbol":"Config","correct":"import type { Config } from 'sql-language-server'"},{"note":"Primarily an executable server. This type defines specific SQL-related options within the server configuration. Used for type checking client-side configurations rather than direct library usage.","symbol":"SQLOption","correct":"import type { SQLOption } from 'sql-language-server'"},{"note":"Primarily an executable server. This constant provides the name identifier for the language server. While exported, the main interaction is running the server, not importing this constant into an application.","symbol":"LSP_SERVER_NAME","correct":"import { LSP_SERVER_NAME } from 'sql-language-server'"}],"quickstart":{"code":"npm install -g sql-language-server\n\n# To run the language server, typically it's invoked by an LSP-enabled editor\n# or manually via standard I/O (stdio) for debugging/testing:\nsql-language-server --stdio\n\n# Example of how an LSP client (e.g., in a VS Code extension) might start it:\n// In a client-side extension's activate() function:\n// import * as path from 'path';\n// import { LanguageClient, LanguageClientOptions, ServerOptions, TransportKind } from 'vscode-languageclient/node';\n\n// let serverModule = context.asAbsolutePath(path.join('node_modules', 'sql-language-server', 'lib', 'main.js'));\n// let debugOptions = { execArgv: ['--nolazy', '--inspect=6009'] };\n\n// let serverOptions: ServerOptions = {\n// \trun: { module: serverModule, transport: TransportKind.stdio },\n// \tdebug: { module: serverModule, transport: TransportKind.stdio, options: debugOptions }\n// };\n\n// let clientOptions: LanguageClientOptions = {\n// \tdocumentSelector: [{ scheme: 'file', language: 'sql' }],\n// \tsynchronize: { fileEvents: workspace.createFileSystemWatcher('**/.sql') }\n// };\n\n// let client = new LanguageClient('sqlLanguageServer', 'SQL Language Server', serverOptions, clientOptions);\n// client.start();","lang":"typescript","description":"Demonstrates how to install the SQL Language Server globally and run it via standard I/O. Includes a commented example of how an LSP client in a VS Code extension might programmatically start and connect to the server process."},"warnings":[{"fix":"Review the `vscode-languageserver` changelog for `8.0.0-next.8` and update any custom client or host code that directly interacts with the LSP client/server libraries to ensure compatibility with the new API.","message":"Upgrading `vscode-languageserver` to version `8.0.0-next.8` in v1.2.1 may introduce breaking changes or require compatibility adjustments for host environments or custom LSP clients relying on older `vscode-languageserver` API contracts.","severity":"breaking","affected_versions":">=1.2.1"},{"fix":"Upgrade to v1.3.0 or newer to benefit from the fix addressing the double-boot issue. Ensure proper lifecycle management of the server process within your LSP host environment.","message":"Prior to v1.3.0, the server could be inadvertently booted twice in certain integration scenarios, leading to unexpected behavior or resource consumption issues.","severity":"gotcha","affected_versions":"<1.3.0"},{"fix":"Upgrade to v1.2.1 or newer to resolve issues with double-quoted identifiers. Ensure your SQL parser configuration is up-to-date with the latest version's parsing capabilities.","message":"Older versions (pre-1.2.1) had issues correctly parsing SQL identifiers enclosed in double quotes, leading to incorrect linting or autocompletion.","severity":"gotcha","affected_versions":"<1.2.1"},{"fix":"Implement robust client-side validation or interpret diagnostics provided by the language server. Do not assume the absence of an error throw implies completely successful parsing in all contexts; instead, rely on the diagnostic messages provided by the LSP.","message":"Version 1.3.3 introduced a change to 'not throw an error when it's failed to parse'. While this improves resilience, it might mask underlying syntax issues if clients rely on explicit parse errors for strict validation.","severity":"gotcha","affected_versions":">=1.3.3"}],"env_vars":null,"last_verified":"2026-04-19T00:00:00.000Z","next_check":"2026-07-18T00:00:00.000Z","problems":[{"fix":"Ensure the `sql-language-server` is correctly configured with the database connection details (e.g., PostgreSQL, SQLite). Manually trigger a schema refresh or restart the language server if the database schema has recently changed.","cause":"The language server's internal schema cache is outdated or incorrect for the current database connection or SQL dialect being used.","error":"Error: Column 'column_name' not found in table 'table_name'"},{"fix":"Ensure the language server is launched from the correct working directory that contains your SQL project. Verify client-side LSP configurations that specify the `rootPath` or `workspaceFolders` are pointing to valid directories.","cause":"The language server could not correctly determine its root directory or configuration files, often due to an incorrect working directory or misconfigured client-side settings.","error":"Failed to resolve root path config"},{"fix":"Upgrade to `sql-language-server` version 1.6.0 or newer, which contains a fix for this specific parsing error. If upgrading isn't an option, rephrase the SQL query to avoid the problematic `IS NOT NULL` pattern if possible.","cause":"Older versions of the parser had a bug in correctly handling the right-hand side of `IS NOT NULL` operations.","error":"Syntax error near 'IS NOT NULL' operation."}],"ecosystem":"npm"}