Skip to content

feat(jetbrains): add plugin pre-installation support#731

Open
Harsh9485 wants to merge 14 commits intocoder:mainfrom
Harsh9485:Pre-Install-jetBrains-Plugins-support
Open

feat(jetbrains): add plugin pre-installation support#731
Harsh9485 wants to merge 14 commits intocoder:mainfrom
Harsh9485:Pre-Install-jetBrains-Plugins-support

Conversation

@Harsh9485
Copy link
Contributor

@Harsh9485 Harsh9485 commented Feb 16, 2026

Description

Adds a jetbrains_plugins parameter to the JetBrains module.
This parameter accepts a map of JetBrains Marketplace plugin IDs and installs them automatically when the workspace starts.

/claim #208

Approach

  1. Uses the JetBrains Marketplace API to download plugins:https: <plugins.jetbrains.com/pluginManager?action=download&id=<pluginId>&build=<productCode>-<buildNumber>

  2. Stores IDE metadata (name and build number) in ide_config.json, generated during Terraform apply.
    The build number is used to construct the correct Marketplace download URL for each IDE.

  3. Plugin installation runs asynchronously using nohup, so the workspace becomes ready immediately.
    The IDE installation is not blocked, and users can start using the workspace while plugins are being installed in the background.

Changes

  • Adds jetbrains_plugins variable of type map(list(string))
    Example:
    { "PY" = [ "com.koxudaxi.pydantic", "com.intellij.kubernetes" ] }
    Allows installing different plugins per IDE.

  • scripts/install_plugins.sh:
    Downloads plugins using the Marketplace API
    Detects whether the plugin is a ZIP or JAR
    Installs it into the correct IDE plugin directory

videos

1 video setup:- https://drive.google.com/file/d/1WB5jRkCOM0w4rEUY-za_3hEvo116UCGd/view?usp=sharing

2 video proof:- https://drive.google.com/file/d/1ZeGUJPJ-gSGNvNzwq8_V-cozz2NqveUT/view?usp=sharing

Type of Change

  • New module
  • New template
  • Bug fix
  • Feature/enhancement
  • Documentation
  • Other

Module Information

Path: registry/coder/modules/jetbrain
New version: v1.0.0
Breaking change: [ ] Yes [ ] No

Testing & Validation

  • Tests pass (bun test)
  • Code formatted (bun fmt)
  • Changes tested locally

@Harsh9485
Copy link
Contributor Author

@DevelopmentCats @matifali, PR is ready for review.

@DevelopmentCats
Copy link
Contributor

I am testing this and will let you know how it goes with a review

@DevelopmentCats
Copy link
Contributor

After some testing it seems to work well. I tested with various different plugins and different IDE's in the toolbox and it is working great. I will look this over and make sure everything looks good with the module code, and I think we will be good to go.

@Harsh9485
Copy link
Contributor Author

Hey @DevelopmentCats @matifali, can we finish it today?

@DevelopmentCats
Copy link
Contributor

One thing that I notice might be useful here @Harsh9485 is if you were to log which IDE the plugins are being installed for in the install_plugins.log

We are on the home stretch here we are just awaiting one more review on this and we should be good to go 😸

@blinkagent
Copy link
Contributor

blinkagent bot commented Feb 19, 2026

Bug: IntelliJ IDEA plugin directory name mismatch

The get_data_dir_for_code() function in install_plugins.sh constructs the plugin directory by concatenating the name from ide_config.json with the version. For IU, the name is IntelliJ IDEA, so the script writes plugins to:

~/.local/share/JetBrains/IntelliJ IDEA2025.3/

But JetBrains uses IntelliJIdea (camelCase, no space) for the actual directory:

~/.local/share/JetBrains/IntelliJIdea2025.3/

Plugins for IntelliJ IDEA are written to the wrong path and never picked up by the IDE.

All other IDEs are unaffected because their display names match their directory names:

Code ide_config name Script output Actual directory Match
CL CLion CLion2025.3 CLion2025.3 Yes
GO GoLand GoLand2025.3 GoLand2025.3 Yes
IU IntelliJ IDEA IntelliJ IDEA2025.3 IntelliJIdea2025.3 No
PS PhpStorm PhpStorm2025.3 PhpStorm2025.3 Yes
PY PyCharm PyCharm2025.3 PyCharm2025.3 Yes
RD Rider Rider2025.3 Rider2025.3 Yes
RM RubyMine RubyMine2025.3 RubyMine2025.3 Yes
RR RustRover RustRover2025.3 RustRover2025.3 Yes
WS WebStorm WebStorm2025.3 WebStorm2025.3 Yes

Ref: https://intellij-support.jetbrains.com/hc/en-us/articles/206544519

Suggested fix: add a product-code-to-directory-name mapping in the script rather than relying on the display name, or add a dir_name field to ide_config.

@DevelopmentCats
Copy link
Contributor

Bug: IntelliJ IDEA plugin directory name mismatch

The get_data_dir_for_code() function in install_plugins.sh constructs the plugin directory by concatenating the name from ide_config.json with the version. For IU, the name is IntelliJ IDEA, so the script writes plugins to:

~/.local/share/JetBrains/IntelliJ IDEA2025.3/

But JetBrains uses IntelliJIdea (camelCase, no space) for the actual directory:

~/.local/share/JetBrains/IntelliJIdea2025.3/

Plugins for IntelliJ IDEA are written to the wrong path and never picked up by the IDE.

All other IDEs are unaffected because their display names match their directory names:

Code ide_config name Script output Actual directory Match
CL CLion CLion2025.3 CLion2025.3 Yes
GO GoLand GoLand2025.3 GoLand2025.3 Yes
IU IntelliJ IDEA IntelliJ IDEA2025.3 IntelliJIdea2025.3 No
PS PhpStorm PhpStorm2025.3 PhpStorm2025.3 Yes
PY PyCharm PyCharm2025.3 PyCharm2025.3 Yes
RD Rider Rider2025.3 Rider2025.3 Yes
RM RubyMine RubyMine2025.3 RubyMine2025.3 Yes
RR RustRover RustRover2025.3 RustRover2025.3 Yes
WS WebStorm WebStorm2025.3 WebStorm2025.3 Yes
Ref: https://intellij-support.jetbrains.com/hc/en-us/articles/206544519

Suggested fix: add a product-code-to-directory-name mapping in the script rather than relying on the display name, or add a dir_name field to ide_config.

@Harsh9485 All of the other IDE's work fine this is the only one that has issues.

@blinkagent
Copy link
Contributor

blinkagent bot commented Feb 19, 2026

@Harsh9485 Thanks for the update addressing the IntelliJ IDEA directory name. A few issues in the latest commit:

1. RustRover directory name is wrong

Line 49 maps RR to ReSharper instead of RustRover. ReSharper is a .NET tool without a standalone Linux IDE. This should be RustRover.

2. Hardcoded build numbers will go stale

get_build_for_code() duplicates the build numbers from the ide_config defaults in main.tf. When JetBrains releases new versions, main.tf gets updated (via API or bumping defaults) but the shell script values will be stale. Two places to maintain instead of one source of truth.

3. Suggestion: use ide_config.json instead of hardcoding

The previous version of this PR wrote ide_config.json to disk from Terraform and read it with jq in the script. That was the right approach since it kept a single source of truth in main.tf. I'd suggest going back to that but adding a dir_name field to ide_config so the script can read both the build number and directory name dynamically rather than hardcoding either.

@Harsh9485
Copy link
Contributor Author

@DevelopmentCats, Done!

Screenshot 2026-02-19 214310 Screenshot 2026-02-19 214300

@Harsh9485
Copy link
Contributor Author

hey @DevelopmentCats, could you let me know who will be reviewing the code next?

@Harsh9485
Copy link
Contributor Author

Hey @DevelopmentCats @matifali, any update?

@DevelopmentCats
Copy link
Contributor

Sorry for the delay on this. We were interfacing with JetBrains to see if they had any insight on this.

Based on our correspondence it looks like InstallPlugins is the proper way to install plugins with this, but based on our previous work together it clear that this is sub-optimal since it requires the ide to be installed in the workspace. One option we could do is revert back to the InstallPlugins method, but add a warning about needing to require the ide to be installed in the workspace first.

Have you attempted this in your work up til now, or do you have any thoughts on this? @Harsh9485

@Harsh9485
Copy link
Contributor Author

Harsh9485 commented Feb 28, 2026

Sorry for the delay on this. We were interfacing with JetBrains to see if they had any insight on this.

Based on our correspondence it looks like InstallPlugins is the proper way to install plugins with this, but based on our previous work together it clear that this is sub-optimal since it requires the ide to be installed in the workspace. One option we could do is revert back to the InstallPlugins method, but add a warning about needing to require the ide to be installed in the workspace first.

Have you attempted this in your work up til now, or do you have any thoughts on this? @Harsh9485

@DevelopmentCats

I understand your idea. First, we can mention that if someone wants to use pre-installed plugins, they should first create the workspace, install the IDE, and then restart the workspace. At that time, the scripts will run and check whether any IDE is installed. If yes, the script will install all the plugins. This approach also solves the race condition that occurred in my previous PR.

So yes, I think that idea is good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants