blog.jetbrains.com

IDE Workspaces Development: Challenges and Plans

It’s been a while since we announced workspaces for IntelliJ IDEA – a feature that lets you manage multiple projects in a single IDE window – and we’ve received tons of feedback and made a lot of improvements since then. We see this feature as a tool to improve the developer experience by allowing you […]

Mar 26, 2025 - 12:53

IDE Workspaces Development: Challenges and Plans

It’s been a while since we announced workspaces for IntelliJ IDEA – a feature that lets you manage multiple projects in a single IDE window – and we’ve received tons of feedback and made a lot of improvements since then. We see this feature as a tool to improve the developer experience by allowing you to:

Conveniently arrange multiple projects in a single IDE window so you can work on them without switching contexts.
Share pre-defined setups for multiple projects via a workspace definition with the projects’ settings.
Save system resources by performing a partial workspace checkout and loading required projects later on.

With the new major IntelliJ IDEA release coming soon, you may be wondering whether workspaces will be released as a stable feature or remain in incubation. The answer is that the feature will stay in the preview state for a while longer. We’ve decided not to deliver it as part of version 2025.1. Instead, we’re addressing inconsistencies in IntelliJ IDEA workflows to improve the user experience of workspaces. In this article, you’ll find a detailed explanation of the reasons behind this decision and information about what you can expect with the next plugin update.

TL;DR: The workspaces feature is more than just a folder for multiple projects. It is an additional workflow, and it affects a lot of areas in the IDE. Since the IntelliJ Platform was not developed with the concept behind workspaces in mind, we need to make some improvements in order to be able to make the feature really helpful.

Where are the pain points?

One of the most important things we were aiming to deliver in IntelliJ IDEA 2025.1 was the ability to share workspaces via VCS, so developers would be able to collaborate using pre-defined workspaces with proper settings, run configurations, etc. However, there were some impediments.

First, sharing the full internal state of a workspace is tricky. If you’ve ever opened the .idea folder, you may have seen a lot of .xml files. Those are descriptors for data sources, run configurations, bookmarks, VCS settings, compiler settings, etc. It turned out that these files change asynchronously and inconsistently across different IDE instances. This makes it hard to synchronize via VCS in a single commit. If two developers were to use the same workspace and commit it to a VCS, the next pull could unpredictably break the state of someone else’s workspace.

Second, IntelliJ IDEA’s UI workflows were mainly designed for the “one-repository – multi-module project” approach, and some still remain that way. We’re working on pinpointing these specific workflows and bringing them in line with new development workflows.

As an example, compare the previous Create New Branch dialog to the new one we introduced for a multi-repository development environment. Unlike the previous version, the new version allows you to select a VCS root for branching.

Third, similar to the UI workflows, some core features, like syncing from build tools, are based on assumptions that make them unfit for the multi-project scenario.

Fourth, some plugins have been generating code files, performing config searches, etc. in workspaces but not in their “home” projects. This can be irritating, as you might find a file in the wrong place, and it can even break application code.

The list is not exhaustive – there are other smaller issues we are working on. We are gradually improving the UI, internal APIs, and UX workflows to make workspaces easy to use and reliable.

What are we doing?

To make things easier for everyone, we’ve decided to change our approach and simplify state storage for workspaces. Now, a workspace is responsible for storing two things:

The workspace folder structure.
Projects’ VCS roots.

Everything else, like run configurations, compiler settings, etc., should remain on the project level, where it can be managed locally. Basically, you can share a workspace as a single XML file, which looks like this.

This solution allows us to implement a bunch of new features in addition to simplifying workspace sharing via VCS.

Partial project checkout

Since a workspace is now essentially a list of projects, when a developer checks out, they can select which projects to fetch into the local file system. Other projects will be present in the structure but won’t be downloaded. So, if an organization has a workspace that contains all microservices, a developer can check out only the ones required for their tasks.

Project unload

We’ve implemented an action that unloads project source code and made it a first-class citizen in workspaces. Now if you have too many projects in your workspace on disk, you can unload some of them to reduce the workload of IntelliJ IDEA for indexing, resolving references, etc. (allowing you to spend less time waiting). Files on the disk stay intact, so the project can be loaded again if required.

Workspace-wide dependency reference

It’s common to update libraries along with the app they are used from. The problem is that you usually need to republish the library to the local repository after every change to be able to use a new version in the application.

With workspaces, we can solve this problem: IntelliJ IDEA resolves dependencies across projects in a workspace and runs the application with updated code, bypassing the “publish to repository” stage.

The “update library code -> publish -> update dependency in app -> run app -> debug” cycle becomes “update library code -> run app -> debug”. It currently works fine for Maven-based projects, and we’re working on making the Gradle experience the same. In order to deploy the app to production or to run it from the command line, you’ll still need to publish the libraries to the repository as usual.

Conclusion

Workspaces are evolving and we’re actively developing them. The IntelliJ IDEA codebase is big and has a long history, and the implementation of workspaces affects a lot of workflows. So, we are taking the time to ensure this feature meets the standards expected in IntelliJ IDEA, prioritizing stability and usability. This is the main reason why it will stay in an incubation state for a while.

In the next major plugin update for IntelliJ IDEA 2025.1, we’re planning to deliver:

Workspace sharing via VCS and partial checkout.
The ability to unload projects from the workspace without removing them from the disk.
On-the-fly library updates on app run for Maven-based projects, with Gradle to follow in the future.

We hope that these features will improve your development experience and productivity. Thanks for your valuable feedback, comments, issues, and suggestions; they are very much appreciated! Feel free to post your thoughts in the corresponding issue in YouTrack or leave a comment below this blog post.

Happy developing!