JetBrains Platform
Plugin and extension development for JetBrains products.
LSP API 现已面向所有 IntelliJ IDEA 用户和插件开发者开放
在 JetBrains IDE 中，开发者创建实现语言服务器协议 (LSP) 的插件的方式正迎来重大变革。 随着 PyCharm 与 IntelliJ IDEA 采用统一分发模式，我们移除了 IntelliJ 平台生态中阻碍 LSP 采用的关键障碍。 从 IntelliJ IDEA Ultimate 2025.2 版本开始，即使订阅到期，用户仍可以继续使用包含 LSP API 在内的部分限定功能。 Community Edition (CE) 在 2025.2 版本中仍会提供，但将不再支持 LSP。 如需了解详情，请查看我们的另一则公告。
LSP 可用性的关键变化
最重要的更新影响 JetBrains IDE 中 LSP 功能的分发方式：
即时影响 (2025.2)：目前已对 IntelliJ IDEA Ultimate 用户开放的 LSP API，在用户订阅到期后，将以限定功能集形式免费提供。 这项变化回应了插件开发者与小众语言社区长期以来的反馈，确保用户在选择开发平台时无需再考虑许可限制。
未来变化 (2025.3)：随着全新统一分发模式的推行，传统的 Community Edition 将停用。 所有用户将下载同一个 IntelliJ IDEA 安装程序，其中 IntelliJ IDEA Ultimate 的专属功能需要解锁订阅才能使用，但 LSP 支持将对所有用户开放。
LSP 实现本身仍为闭源商业代码，但我们将持续免费向第三方插件完全开放其使用权限。 这意味着插件开发者如今可以面向更广泛的用户群体开发插件，而无需用户购买 IntelliJ IDEA 许可证。
对插件开发者而言，这意味着什么？
这项变化解决了开发者社区长期以来的核心痛点之一。 在此之前，使用 LSP 的插件本质上仅能供 IntelliJ IDEA Ultimate 用户使用，这给以下群体带来了不小的阻碍：
- 开源插件开发者：希望提供基于 LSP 的语言支持，却不愿限制自己的用户群体；
- 小众语言社区：要求用户付费订阅使采用变得不切实际，对于小型团队或独立贡献者来说更是如此；
- 教育场景：管理不同的 IDE 版本会增加不必要的复杂度与操作成本。
在统一分发模式下，插件开发者现在可以：
- 构建适用于所有 JetBrains IDE 用户的基于 LSP 的插件；
- 降低向用户解释安装要求的复杂度；
- 与那些已提供全平台 LSP 支持的竞品扩展程序更高效地竞争。
当前 LSP 功能与设置
自从在 2023.2 版本中引入以来，IntelliJ 平台中的 LSP API 已日趋成熟，目前支持以下功能：
核心语言功能：
- 支持解析的代码补全
- 转到定义与类型定义
- 悬停查看文档
- 查找引用定义
- 语义高亮显示
- 诊断（包含推送与拉取两种模式）
高级功能:
- 代码操作与快速修复
- 文档格式设置
- 文档链接与颜色预览
- 意图操作
- 工作空间命令
插件开发者应当以 IntelliJ IDEA Ultimate 2025.2.1+ 版本为目标，并在 plugin.xml 文件中添加对 com.intellij.modules.lsp 模块的可选依赖。
<idea-plugin> <depends optional=”true” config-file="lsp.xml">com.intellij.modules.lsp</depends> </idea-plugin>
要确保插件仅能在 2025.2.1 及更高版本中安装，请在 build.gradle.kts 文件中指定 since-build 属性：
intellijPlatform {
pluginConfiguration {
ideaVersion {
sinceBuild = "252.25557"
}
}
}
如果您的项目基于插件模板开发，请在 gradle.properties 文件中设置相应构建版本号：
pluginSinceBuild=252.25557
- 要集成 Kotlin LSP，需要两个组件：
- LSP 服务器描述符：指定支持的文件，并提供用于以独立进程形式启动服务器的命令行；
- LSP 支持提供程序：确保指定文件可以调用该服务器。
服务器描述符
以下 KotlinLspServerDescriptor 为 Kotlin 语言服务器创建了一个 LSP 支持提供程序，用于处理 Kotlin 文件（扩展名为 .kt）。 该提供程序会确保语言服务器通过 PATH 环境变量中可用的 kotlin-lsp 二进制文件，以独立进程形式运行。
private class KotlinLspServerDescriptor(project: Project)
: ProjectWideLspServerDescriptor(project, "KN Kotlin LSP") {
override fun isSupportedFile(file: VirtualFile) =
file.extension == "kt"
override fun createCommandLine() =
GeneralCommandLine("kotlin-lsp", "--stdio")
}
LSP 支持提供程序
创建 LSP 支持提供程序，在需要时通过对应的服务器描述符启动 LSP 服务器。
class KotlinLspServerSupportProvider : LspServerSupportProvider {
override fun fileOpened(
project: Project,
file: VirtualFile,
serverStarter: LspServerSupportProvider.LspServerStarter,
) {
if (file.extension == "kt") {
serverStarter.ensureServerStarted(
KotlinLspServerDescriptor(project)
)
}
}
}
该 LSP 支持提供程序必须在插件描述符中（主 plugin.xml 旁的现有 lsp.xml 文件内）注册。
<idea-plugin>
<extensions defaultExtensionNs="com.intellij">
<platform.lsp.serverSupportProvider
implementation="com.example.KotlinLspServerSupportProvider"/>
</extensions>
</idea-plugin>
上述 LSP 实现可以参考 Kotlin Notebook 示例：https://github.com/Kotlin/kotlin-notebook-intellij-platform/blob/master/examples/lsp.ipynb
权衡考量
IntelliJ 平台文档中对 LSP 的定位有明确说明：LSP 不应被视为现有语言 API 的替代，而应作为一种增值方案。 尽管 LSP 开发具备显著优势（如降低维护成本、缩短开发周期、保障跨平台一致性），但仍需注意以下局限性：
- IDE 集成度有限：LSP 无法充分调用 IntelliJ 平台中通过程序结构接口 (PSI) 深度集成的强大原生功能；
- 性能考量：与原生实现相比，基于 LSP 的插件会引入额外的通信开销；
- 功能对等性差距：某些高级 IDE 功能目前尚无对应的 LSP 实现，这对部分插件开发者的功能范围造成了限制。
对于希望降低复杂度、扩大用户覆盖范围，同时提供一致语言支持的插件开发者而言，LSP 是一种实用的轻量级方案。 而如果需要与 IntelliJ 平台功能进行更深度的集成，PSI 等原生 API 仍是首选。
LSP 开发入门
要探索 LSP 集成，插件开发者应按以下步骤操作：
- 查阅 IntelliJ 平台插件 SDK 中的全面文档；
- 参考现有实现（如开源的 Prisma ORM 插件）；
- 从基础功能入手，逐步添加更复杂的功能；
- 针对 2025.2 版本进行规划，以充分利用全平台 LSP 支持。
总结与展望
移除 IntelliJ 平台中 LSP 集成的商业许可限制，为插件开发者解决了一大核心难题，使其能将精力集中在效率提升与功能开发上。
更重要的是，这项转变不仅是技术层面的调整，它凸显了 JetBrains 的核心理念，即语言服务器开发应面向更广泛的开发者社区，而非仅局限于商业产品开发群体。
尽管 LSP 集成无法替代所有原生 API，但它为在所有 JetBrains IDE 中提供一致的语言支持提供了实用的轻量级解决方案。 这将促进竞争，也为插件开发者带来覆盖更广泛用户群体的机遇。 随着 2025.2 版本的发布，插件开发者如今可以基于技术本身的优势评估并采用 LSP，无需再受许可限制的束缚。
本博文英文原作者：
Subscribe to JetBrains Platform updates
Discover more
The LSP API Is Now Available to All IntelliJ IDEA Users and Plugin Developers
The way developers create plugins implementing the Language Server Protocol (LSP) in JetBrains IDEs is undergoing a significant shift. With PyCharm and IntelliJ IDEA adopting a unified distribution model, we’re removing a key obstacle that has been limiting LSP adoption within the IntelliJ Platform ecosystem. Starting with IntelliJ IDEA Ultimate 2025.2, users can continue using a limited set of features, including the LSP API, even after their subscription expires. Community Edition (CE) will still be available in 2025.2 but will not include LSP support. See our other announcement to learn more.
Key changes in LSP availability
The most important update affects how LSP functionality is distributed in JetBrains IDEs:
Immediate impact (2025.2): The LSP API, which is already available to IntelliJ IDEA Ultimate users, will now be accessible for free within a limited feature set when their subscription expires. This change addresses long-standing feedback from plugin developers and smaller language communities, ensuring users no longer need to consider licensing restrictions when choosing between platforms.
Future changes (2025.3): With the new unified distribution, the traditional Community Edition will be sunset. All users will download a single IntelliJ IDEA installer, with IntelliJ IDEA Ultimate features requiring a subscription to be unlocked, but LSP support will remain available to everyone.
The LSP implementation itself stays closed-source and commercial, but we’ll keep it fully accessible for third-party plugins at no charge. This means plugin developers can now target a much broader user base without requiring their users to purchase the IntelliJ IDEA license.
What does this mean for plugin developers
This change addresses one of the most persistent complaints from the developer community. Previously, plugins using the LSP were essentially limited to IntelliJ IDEA Ultimate users, creating a significant barrier for:
- Open-source plugin developers who wanted to provide LSP-based language support without restricting their user base.
- Niche language communities, where requiring a paid subscription made adoption impractical, especially for small teams or individual contributors.
- Educational environments, where managing different IDE editions added unnecessary complexity and friction.
The unified approach means plugin developers can now:
- Build LSP-based plugins that work for users of all JetBrains IDEs.
- Reduce the complexity of explaining installation requirements to users.
- Compete more effectively with competitors’ extensions, which have had universal LSP support.
Current LSP capabilities and setup
The LSP API in the IntelliJ Platform has matured significantly since its introduction in 2023.2 and currently supports the following:
Core language features:
- Code completion with resolve support
- Go to definition and type definition
- Hover documentation
- Find references definition
- Semantic highlighting
- Diagnostics (both push and pull models)
Advanced features:
- Code actions and quick-fixes
- Document formatting
- Document links and color preview
- Intention actions
- Workspace commands
Plugin developers should target IntelliJ IDEA Ultimate 2025.2.1+ and include the optional dependency on the com.intellij.modules.lsp module in the plugin.xml file.
<idea-plugin> <depends optional=”true” config-file="lsp.xml">com.intellij.modules.lsp</depends> </idea-plugin>
To ensure the plugin is only available for installation in 2025.2.1+ and later, specify the since-build property in your build.gradle.kts file with:
intellijPlatform {
pluginConfiguration {
ideaVersion {
sinceBuild = "252.25557"
}
}
}
If your project is based on the Plugin Template, set the relevant build number in the gradle.properties file:
pluginSinceBuild=252.25557
- To integrate the Kotlin LSP, two components are needed:
- An LSP server descriptor that specifies supported files and offers a command line to launch the server as a standalone process.
- An LSP support provider that ensures the server is accessible for a given file.
Server Descriptor
The following KotlinLspServerDescriptor creates an LSP support provider for the Language Server for Kotlin that handles Kotlin files (.kt extension). The provider will ensure that the language server runs in a separate process from the kotlin-lsp binary available in the PATH environment variable.
private class KotlinLspServerDescriptor(project: Project)
: ProjectWideLspServerDescriptor(project, "KN Kotlin LSP") {
override fun isSupportedFile(file: VirtualFile) =
file.extension == "kt"
override fun createCommandLine() =
GeneralCommandLine("kotlin-lsp", "--stdio")
}
LSP Support Provider
Create an LSP support provider that initiates the LSP server when needed, using the appropriate server descriptor.
class KotlinLspServerSupportProvider : LspServerSupportProvider {
override fun fileOpened(
project: Project,
file: VirtualFile,
serverStarter: LspServerSupportProvider.LspServerStarter,
) {
if (file.extension == "kt") {
serverStarter.ensureServerStarted(
KotlinLspServerDescriptor(project)
)
}
}
}
The LSP support provider must be registered in the plugin descriptor, next to the main plugin.xml, within the existing lsp.xml file.
<idea-plugin>
<extensions defaultExtensionNs="com.intellij">
<platform.lsp.serverSupportProvider
implementation="com.example.KotlinLspServerSupportProvider"/>
</extensions>
</idea-plugin>
You can find the above LSP implementation as a Kotlin Notebook example here: https://github.com/Kotlin/kotlin-notebook-intellij-platform/blob/master/examples/lsp.ipynb
Trade-offs
The IntelliJ Platform documentation is clear about positioning: The LSP approach shouldn’t be considered as a replacement for the existing language API but rather as an added value. While LSP development offers significant advantages, such as reduced maintenance effort, faster development cycles, and cross-platform consistency, it is important to keep the following limitations in mind:
- Limited IDE integration: The LSP approach provides less access to the IntelliJ Platform’s robust native features, which are deeply integrated via the Program Structure Interface (PSI).
- Performance considerations: Using an LSP-based plugin introduces communication overhead compared to native implementations.
- Feature parity gaps: Some advanced IDE features may not currently have LSP equivalents, limiting the scope for certain plugin developers.
The LSP serves as a practical, lightweight solution for plugin developers seeking to reduce complexity and expand their reach while delivering consistent language support. For those who need deeper integration with IntelliJ Platform features, native APIs like the PSI remain the preferred choice.
Getting started with LSP development
To explore LSP integration, plugin developers should:
- Review the comprehensive documentation available in the IntelliJ Platform Plugin SDK.
- Examine existing implementations like the open-source Prisma ORM plugin.
- Start with basic features and gradually add more sophisticated capabilities.
- Plan for the 2025.2 release to leverage universal LSP support.
Wrapping up and looking ahead
Removing commercial licensing for LSP integration on the IntelliJ Platform eliminates a significant problem for plugin developers, allowing them to prioritize efficiency and feature work.
More importantly, this shift represents more than a purely technical change; it underscores JetBrains’ recognition that language server development should be accessible to the broader developer community, not just those building commercial products.
While LSP integration won’t replace every native API, it provides a practical, lightweight solution for delivering consistent language support across all JetBrains IDEs. This fosters competition and presents an opportunity for plugin creators to target a broader audience. With the 2025.2 release, plugin authors can now evaluate and adopt the LSP on its technical merits, free from licensing constraints.