Enable / Disble plug-ins per project

Hi,
are there any plans to implement enable/disbale plugins (per project) in IDEA ? I think it's frustrating loading a bunch unneeded plugins for one project , while they are used in totaly different one.

59
58 comments
Avatar
Permanently deleted user

Hi there. Reviving this thread after 13+ years because I found a legitimate need for this feature. Not just a 'bug' with plugin initialization. My use case revolves around having to switch among multiple projects, one of which is an aggregate gradle project containing > 100 projects. The issue I have is that the gradle project is mostly Java, but a handful of the projects have some ruby environments with rake tasks. This wasn't an issue until I started working in another project that was full ruby. When I started with that I added the Ruby plugin, but now everytime I switch back to the gradle project, IntelliJ tries to run the rake tasks for unused projects and modifies files every time.

Ideally I would be able to exclude the ruby plugin entirely for my gradle project, rather than having to disable it wholesale and restart the IDE.

9

I think we need this ability to enable/disable plugins per projects basis. I think, if you can improve your IDEs (WebStorm, IDEA) that it doesn't need a restart whenever we install/uninstall, enable/disable plugins; you don't even have to build this feature, someone will eventually write a workspace (vscode terminology) like plugin that allows to enable/disable plugins per project.

The restarting process is painful, and it's so old. We are in 2020 with better ways this.

Here are some reasons why we need it:

  1. Plugins like Kite, Codota, Tabnine shouldn't be enabled all the time, or we should have option to enable in a few project.
  2. There are many people who are still using old machines, like me on Macbook Pro early 2011 with 8GB memory, dual core process, small screen (real-estate).  As a software developer we should think of these people who have that kind of configurations, and that works for them -- machines haven't gone slower; developers have made software more resource hungry as computers got much faster; hence the net result is -- user still feels the lag or slowness or discontentment on latest machines as well.When computers were slower we worked harder to optimize to make software faster; now it's otherwise -- we are actually not doing much.
  3. We don't need all plugins in all projects; I work on different kind of projects, for some I use WebStorm (for it's simplicity -- less clutter), and for others I use IDEA. Now if you make sure IDE doesn't need to be restarted, I might actually just use IDEA for every project, and enable/disable plugins as and when it's needed.

You should probably work on the removing the need of restarting the IDE; there are plenty of developers who will build some awesome plugin to make workspace or such things happen.

 

Cheers

Abdul Qabiz

8

I am another developer with multiple frameworks across multiple projects. My WebStorm is slowing down to the point I'm considering ditching Intellij instead of renewing the license. I hope someone from the JetBrains will finally take time to respond here.

 

Thanks

5

I seriously can't believe this is still a thing 16 YEARS LATER! 😑

4

Another use case are plugins which operate on general filetypes e.g. Ansible, Cloudformation, Kubernetes plugins operate on YAML files. These plugins will give different style suggestion/issues and auto-complete suggestions. Manually managing the active plugin is very cumbersome

3

14 years... Upvote.

3

CoPilot, and other similar plugins, can present a major security issue because they can upload the contents of sensitive files to their respective APIs as part of their normal operations, possibly leaking credentials, vulnerability details and more.

I use PHPStorm for working on web apps, but I also work on pentest reports, some of which are very sensitive. I want CoPilot for PHP, but not for pentests. I don't want to train an unknown LLM with unpublished 0-days for it to suggest in other people's code!

3
Avatar
Permanently deleted user

1. Much less crowded interface.
2. Much less exceptions in the EAP's :)).
3. Less memory usage, I suppose, although It depends of the implementation ... anyway - p.1 is quite important for me.

2

And another reason I found today:

Out of curiosity, I wanted to test/check Codota plugin. Codota plugin creators ensure that code is safe and I believe them, though I don't want to use it/test on my commercial projects.

Right now, I'm disabling it every time I want to switch my commercial projects and it is little bit painful. Not a dealbreaker for me, I just wanted to add my opinion.

 

Thanks

2

I want to also support this - for example I dont want to use SonarLint for one of my project (old code which I dont want/need to fix) and it is totally filled with warnings and almost unreadable..

2

+1 As I work simultaneously with several projects (client Angular, server Spring Boot, mobile Nativescript), platorm-specific  plugins interfere with other projects and make big mess in code check-up.

2

Is this still not possible? 15 years has passed, and many people are asking for this, myself included :)

2

+1.

By the way, I am surprised to see that that "Plugins" section is marked with the "Per Project" icon...

2

A Big +100 to this.

I am tired of enabling/disabling plugins based on project context. And every time I enable/disable plugin, I have to restart the IDE, which is another big pain.

Please allow storing required plugins in a file somewhere in `.idea` directory such that only those plugins will be enabled when in a given project is loaded. VSCode does it too.

2

With Github Copilot debut this issue got even hotter.

2

I work for a client that has developed a plugin that modifies the code before each commit to meet their standards. I'd like to isolate that plugin from the rest of my projects.

1
 
If you can't support it, then I will migrate to VS Code.
1

+1 on this.   We have a big mono-repo with both Scala and Java modules.   The scala plugin is so slow and interferes with everything and causes reindexing even by changing files outside the scala modules.   I want to have two projects for this repo - one with the scala plugin disabled and one with it enabled.

1

A new use case. AI Plugins, that are simply not allowed to be enabled for some customer projects, but usable in others.

1
Avatar
Permanently deleted user

Hello lllopo,

Do you see any noticeable effect of the inactive plugins?

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

l> Hi,
l> are there any plans to implement enable/disbale plugins (per project)
l> in IDEA ? I think it's frustrating loading a bunch unneeded plugins
l> for one project , while they are used in totaly different one.


0
Avatar
Permanently deleted user

Hello lllopo,

Any specific details on pt.1?

We'd much rather reduce the UI and performance impact of functionality you
do not use, than provide more ways to remove the functionality.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

l> 1. Much less crowded interface.
l> 2. Much less exceptions in the EAP's :)).
l> 3. Less memory usage, I suppose, although It depends of the
l> implementation ... anyway - p.1 is quite important for me.


0
Avatar
Permanently deleted user

Mostly the tool windows, of course. But I want to notice, that merging the Projects, Packages, J2EE etc. was a bad move imho.

Also - more plugins lead to dramaticaly longer loading times (for example the SQL plugin slows down the loading visibly). I don't know about the runtime performance, but I suppose it's hit by the plugins too, so a good disable impl. can help on that point too probably.

0
Avatar
Permanently deleted user

Hello lllopo,

As for the toolwindows, this is more of a limitation of our windowing system,
which does not provide a standard way to hide unused toolwindows.

As for the performance, this is, to a large degree, a plugin bug. Any plugin
should delay as much of the initialization as possible until the moment when
it's actually used - this will provide more benefits than a general solution
for disabiling plugins.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"

l> Mostly the tool windows, of course. But I want to notice, that
l> merging the Projects, Packages, J2EE etc. was a bad move imho.
l>
l> Also - more plugins lead to dramaticaly longer loading times (for
l> example the SQL plugin slows down the loading visibly). I don't know
l> about the runtime performance, but I suppose it's hit by the plugins
l> too, so a good disable impl. can help on that point too probably.
l>


0
Avatar
Permanently deleted user

I see. 10x for the reply. If that's the logic behind the plugins init, really, it's better to work on the "hide tool windows" feature then (per project ;) ).

0

Please sign in to leave a comment.