跳到正文
cccskills
免费在 GitHub 公开中文介绍

pseudo-kmp

在 IntelliJ 的 JPS 项目中创建或迁移伪 Kotlin Multiplatform 模块,配置源码集和模块设置,并通过 expects 编译器插件将公共声明与平台实现对应起来。

原文查看原文说明

Create or modify IntelliJ pseudo-KMP expect/actual modules.

JetBrains/intellij-community星标 20,685(GitHub 20,685 + cccskills 0)

实测评分 未实测

查看安装方法

适用场景

  • 新建伪 KMP 模块
  • 将现有模块迁移为伪 KMP
  • 关联公共声明与平台函数

中文介绍

功能

本技能介绍如何在 IntelliJ 的 JPS 构建环境中创建或迁移模拟 Kotlin Multiplatform 机制的模块。内容包括公共代码以及 JVM、WasmJs、JS、Native 代码的源码目录布局;在 .iml 中注册支持模块依赖和 expects-compiler-plugin;以及将模块加入结构测试。它还说明如何用 linkToActual() 声明公共函数,并通过 @Actual 注解和平台后缀关联各平台的函数实现。资料也列出允许的库依赖,以及用于标记公共源码集的文件。

适用场景

在 IntelliJ 单体仓库中新建面向多平台的模块,或将现有模块迁移为伪 KMP 结构时,可以使用本技能。如果您需要在同一模块中整理公共代码和平台实现,或核对 .iml 设置、依赖关系和源码根目录,也适用。

使用示例

  • “请说明如何将这个 Kotlin 模块迁移到伪 KMP 结构。”
  • “请添加 JVM actual 函数和对应的公共声明。”

注意事项

该方式只支持顶层函数,公共声明和各平台实现必须位于同一模块中。不要将 WasmJs 源码目录添加为 .iml 中的源码根目录。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
B部分不足资料指定修改后的构建与测试验证,但未说明修改前确认。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足资料依赖 JPS、Kotlin 插件和 Maven 仓库,并提供配置示例。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月28日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md6.7 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

<!-- Generated by community/.ai/render-guides.mjs; edit community/.agents/skills/pseudo-kmp/SKILL.md -->

Pseudo-KMP Modules

The monorepo is compiled by JPS, which does not support Kotlin Multiplatform. To emulate KMP expect/actual declarations, the Fleet team created the expects-compiler-plugin. This skill covers how to set up and work with modules that use this mechanism.

Documentation

Module Configuration Checklist

When creating or migrating a pseudo-KMP module:

  1. Register in the structure test. Add your module name to the multiplatformModules list in com.intellij.ideaProjectStructure.fast.MultiplatformModuleStructureTest (tests/ideaProjectStructure/testSrc/com/intellij/ideaProjectStructure/fast/MultiplatformModuleStructureTest.kt).

  2. Use only allowed library dependencies. The test enforces a closed set:

    • kotlin-stdlib
    • kotlinx-coroutines-core
    • kotlinx-coroutines-debug
    • jetbrains-annotations
    • kotlinx-serialization-core
    • kotlinx-serialization-json
    • kotlin-reflect
    • kotlinx-collections-immutable

    If you need a new library, add it to allowedMultiplatformLibraryDependencies in the test. Dependencies on other multiplatform modules (those in multiplatformModules) are also allowed.

  3. Set up source folders:

    • src/ — common code
    • srcJvm/ or srcJvmMain/ — JVM-specific code (Java code can live here too)
    • srcWasmJs/ or srcWasmJsMain/ — WasmJs-specific code
    • srcJsMain/ — JS-specific code
    • srcNativeMain/ — Native-specific code

    Important: Do NOT add srcWasmJs/srcWasmJsMain as a source root in the .iml file. The IDE would try to compile it in JVM mode.

  4. Add the .pseudoCommonKotlinSourceSet marker file to the common source root (e.g., src/.pseudoCommonKotlinSourceSet). This empty file tells the Kotlin plugin that the source set is common code, preventing Optimize Imports from removing imports that are unnecessary on JVM but mandatory in common code (e.g., @JvmStatic, @JvmField).

IML File Setup

Your .iml file needs two things: the multiplatformSupport dependency and the compiler plugin registration.

Use community/platform/util/multiplatform/intellij.platform.util.multiplatform.iml as a reference. To find the current plugin version, check that file rather than hardcoding.

1. Add the support module dependency (PROVIDED scope)

<orderEntry type="module" module-name="intellij.platform.multiplatformSupport" scope="PROVIDED" />

2. Add the Kotlin facet with expects-compiler-plugin

<facet type="kotlin-language" name="Kotlin">
  <configuration version="5" platform="JVM 1.8" allPlatforms="JVM [1.8]" useProjectSettings="false">
    <compilerSettings>
      <option name="additionalArguments" value="-Xjvm-default=all ..." />
    </compilerSettings>
    <compilerArguments>
      <stringArguments>
        <stringArg name="jvmTarget" arg="1.8" />
        <stringArg name="apiVersion" arg="2.3" />
        <stringArg name="languageVersion" arg="2.3" />
      </stringArguments>
      <arrayArguments>
        <arrayArg name="pluginClasspaths">
          <args>$MAVEN_REPOSITORY$/jetbrains/fleet/expects-compiler-plugin/{VERSION}/expects-compiler-plugin-{VERSION}.jar</args>
        </arrayArg>
      </arrayArguments>
    </compilerArguments>
  </configuration>
</facet>

Replace {VERSION} with the version from the reference IML.

Expect/Actual Pattern

Only top-level functions are supported. Both the expect and actual declarations must be in the same module.

Common side (in src/)

Use linkToActual() as the function body:

import fleet.util.multiplatform.linkToActual

internal fun myFunction(param1: String, param2: Int): Boolean = linkToActual()

Platform side (in srcJvm/, srcWasmJs/, etc.)

Annotate with @Actual. The function name must be the expect function name + platform suffix:

import fleet.util.multiplatform.Actual

@Actual
internal fun myFunctionJvm(param1: String, param2: Int): Boolean {
  // JVM implementation
}

Platform suffixes

PlatformSuffixSource folder
JVMJvmsrcJvm/ or srcJvmMain/
WasmJsWasmJssrcWasmJs/ or srcWasmJsMain/
JSJssrcJsMain/
NativeNativesrcNativeMain/
Multi-platform buildImpl(rare)

Real example

Common (community/platform/util/base/multiplatform/src/com/intellij/util/text/CharArrayUtilKmp.kt):

internal fun getCharsPlatformSpecific(
  sequence: CharSequence, srcOffset: Int, dst: CharArray, dstOffset: Int, len: Int
): Boolean = linkToActual()

JVM actual (community/platform/util/base/multiplatform/srcJvmMain/com/intellij/util/text/jvm.kt):

@Actual
internal fun getCharsPlatformSpecificJvm(
  string: CharSequence, srcOffset: Int, dst: CharArray, dstOffset: Int, len: Int
): Boolean {
  if (string is CharBuffer) { /* ... */ }
  return false
}

Code Conversion Notes

  • The monorepo uses the JVM version of the Kotlin standard library, which differs from the common version. Check which declarations are available in common code.
  • @JvmStatic, @JvmField, and similar annotations are not auto-imported in common code. Import them manually. The .pseudoCommonKotlinSourceSet marker prevents the IDE from removing these imports.
  • Java code can remain in platform-specific source sets (srcJvm/).

After Editing

  1. Run ./build/jpsModelToBazel.cmd after modifying any .iml files.
  2. Run MultiplatformModuleStructureTest to validate module structure:
    ./tests.cmd --module tests.ideaProjectStructure --test com.intellij.ideaProjectStructure.fast.MultiplatformModuleStructureTest
    
  3. Lint changed files with mcp__ijproxy__lint_files.

Artifact Publication

The monorepo does not publish multiplatform artifacts to Maven Central directly. Separate repositories with Gradle infrastructure extract module sources, compile with true KMP, and publish. See fleet-multiplatform-deps and fleet-parser-collection in JetBrains Space.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

actions

免费有简介

实现或修改 IntelliJ `AnAction`,并在 `plugin.xml` 中注册。将显示名称和说明写入消息资源文件,按需设置图标,并通过事件协程作用域启动挂起任务,避免同步处理阻塞 IDE。

  • 为 IDE 菜单添加操作
  • 修改操作注册或图标
  • 整理操作名称和说明
JetBrains/intellij-community2.1万2026年10月29日 更新

bazel-test-migration

免费有简介

将 IntelliJ JPS 测试模块迁移到 Bazel,并排查仅在 Bazel 中出现的失败。根据症状检查依赖、插件、测试数据和 runfiles,重新生成并验证目标。

  • 将 JPS 测试模块迁移到 Bazel
  • 排查仅在 Bazel 中失败的测试
  • 检查测试依赖和数据配置
JetBrains/intellij-community2.1万2026年10月29日 更新

code-style

免费有简介

按 IntelliJ 项目规范编写或审查 Kotlin 和 Java 代码,涵盖语言选择、格式、密封类型、线程注解及控制流异常处理。

  • 按 IntelliJ 规范编写 Kotlin
  • 审查 Java 代码
  • 检查异常处理和密封类型分支
JetBrains/intellij-community2.1万2026年10月29日 更新

commits

免费有简介

本指南帮助您按 IntelliJ 项目规则拆分更改并撰写提交信息:有工单时使用编号和变更说明,无工单时使用标签与子系统名,并在需要时说明原因和决定。

  • 按项目格式编写带工单号的提交信息
  • 整理测试或文档提交并选择合适标签
  • 按规则修改已有提交信息
JetBrains/intellij-community2.1万2026年10月29日 更新

使用多个 Python 类型检查器比较代码片段或文件的类型推断和报错判断,并汇总各工具的结论、耗时与诊断信息,可保存为 Markdown 报告。

  • 比较不同检查器的类型推断
  • 确认代码是否会被判为类型错误
  • 查看多个工具的诊断差异
JetBrains/intellij-community2.1万2026年10月29日 更新

整理 Compose Desktop 界面中的状态和副作用,让可组合函数负责绘制,由展示器或协调器处理应用决策。了解状态归属、Effect、可复用组件接口、延迟列表键、动画和性能,适用于单项界面修改。

  • 分离界面绘制与展示器决策
  • 整理界面状态的归属
  • 检查 Effect 键和协程用法
JetBrains/intellij-community2.1万2026年10月29日 更新

查看 JetBrains 的全部技能

报告此技能的问题