Skip to content
cccskills
FreePublished on GitHub

pseudo-kmp

Set up or migrate IntelliJ pseudo-Kotlin Multiplatform modules in a JPS-based project. It guides source-set layout, module configuration, and matching common declarations with platform-specific implementations using the expects compiler plugin.

OriginalShow the original description

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

JetBrains/intellij-community20,664 stars(GitHub 20,664 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Creating a pseudo-KMP module with common and platform-specific source sets
  • Migrating an IntelliJ module to the pseudo-KMP setup
  • Adding expect/actual-style functions for JVM or other platforms

Files included (1)

  • SKILL.md6.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

<!-- 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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

actions

FreeSummary

Implement or update IntelliJ `AnAction` classes and their `plugin.xml` registrations. Keep labels and descriptions in message bundles, configure optional icons, and launch suspending work through the event coroutine scope so synchronous action handling does not freeze the IDE.

  • Adding a new IntelliJ action
  • Updating an action's registration or icon
  • Moving action labels into a message bundle
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Move IntelliJ JPS test modules to Bazel and diagnose failures that occur only under Bazel. The guide helps trace missing dependencies, plugins, test data, and runfiles, then verify the generated target and migrated tests.

  • Migrating a JPS test module to Bazel
  • Diagnosing a test failure that occurs only in Bazel
  • Checking Bazel dependencies and test data wiring
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

code-style

FreeSummary

Write or review Kotlin and Java code in line with IntelliJ project conventions. The guidance covers language choice, formatting, sealed types, threading annotations, and safe handling of control flow exceptions so changes fit the surrounding codebase.

  • Writing a new Kotlin file that follows IntelliJ conventions
  • Reviewing Java code and checking its style guidance
  • Checking formatting, sealed-type handling, or exception handling
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

commits

FreeSummary

Create, amend, or rename IntelliJ commits with messages that follow the project’s ticket and label formats. Keep each commit focused, explain the reason and decision in the body when needed, and pass the message safely through the shell or PowerShell.

  • Writing a message for a change linked to a YouTrack ticket
  • Preparing a commit message for tests, cleanup, or documentation
  • Amending or renaming an existing IntelliJ commit
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Compare how Python type checkers interpret a code snippet or file. The script runs selected tools, including ty, pyrefly, basedpyright, mypy, and zuban, then produces a Markdown report with verdicts, timings, and each checker's diagnostic output.

  • Comparing type inference for a Python snippet
  • Checking whether a Python expression should be a type error
  • Reviewing differences among Python type checkers
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Shape Compose Desktop UI code by keeping composables focused on rendering and placing application decisions in presenters or coordinators. Get guidance on state ownership, effects, reusable component APIs, lazy-list keys, animation, and performance for individual UI changes.

  • Separating screen rendering from application decisions
  • Choosing which UI state belongs in composition
  • Structuring effects and coroutine work
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

See all skills by JetBrains

Report a problem with this skill