On-demand computation of module kind in split-mode

IntelliJ Platform
1

Hi,

I’m splitting a plugin that has several dependencies on platform plugins and modules, specifically this:

module A:
  - plugin com.intellij.microservices.ui
  - module B

module B:
  - plugin org.jetbrains.plugins.yaml
  - module intellij.platform.langInjection
  - module C

module C:
  - module: intellij.platform.backend
  - com.intellij.modules.json

I’m wondering if there is a way to compute (with an action, intention, etc.) on-demand what kind a specific module of my plugin is: backend, frontend or shared.

The reason I’m asking:

  • I have an AnAction in module A whose actionPerformed() calls into module B.
  • If module A would be a frontend module (which I’m guessing is not), then I’d need an RPC API to call into module B.
  • However, if both module A and B are backend or at most shared, there would be no need for RPC.

So, I’m asking for help for:

  • would there be any indication of incorrect/missing splitting in this case when testing the plugin in the IDE with Split Mode enabled?
  • and if there is a way to compute a module’s kind to aid the development process.

Thanks!

2

module C is backend because it depends on intellij.platform.backend.

module B is backend, because it depends on module C, which is backend.

module A is backend, because it depends on module B, which is backend.

The kind of a module is defined by its dependencies (intellij.platform.backend says it’s backend, intellij.platform.frontend say’s it’s frontend, if none then it’s shared).
Ideally, the module’s .xml descriptor should have the right backend/frontend dependency.

At least 2026.2 has inspections to warn you about extensions placed in the wrong module type (made for intellij-community, still has a few issues with 3rd-party naming of some projects).

3

Thanks @jansorg, it’s clearer now!

Yeah, I’m aware of those inspections, I actually used them when preparing for the migration to split mode.

I was trying to determine how the types of module A and B would change when C is backend but A and/or B pull in plugins/modules with both backend and UI modules. E.g. I’m presuming that intellij.platform.langInjection is rather backend, but going through its dependencies it was not entirely clear that it is.

4

I ended up with a lot of modules:

  • module-a-shared
  • module-a-frontend
  • module-a-backend

and the same for module-b and module-c.

In your setup, module-a-frontend would probably be a frontend module and depend on module-a-shared and com.intellij.microservices.ui (is that a plugin or module?) and module-b-frontend (if that’s necessary).

module-a-backend would depend on module-b-backend (+ module-b-shared, if needed) and so on.

That’s similar to intellij-community, which split a lot of plugins into even more modules (shared/backend/frontend).

5

Yeah, I’ll probably need to split modules even more.

Meanwhile, I realized that the line markers on <idea-plugin> tags that navigate back to the modules’ registrations in plugin.xml show a different icon based on the module kind, and their tooltips too mention the type:

  • backend: image
  • frontend: image
  • shared: image