Enable / Disble plug-ins per project 关注
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.
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.
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:
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.
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.
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
14 years... Upvote.
I seriously can't believe this is still a thing 16 YEARS LATER! 😑
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.
Is this still not possible? 15 years has passed, and many people are asking for this, myself included :)
+1. Here is another reason for it - https://youtrack.jetbrains.com/issue/IDEA-256900
By the way, I am surprised to see that that "Plugins" section is marked with the "Per Project" icon...
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.
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..
+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.
+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.
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.
Do you see any noticeable effect of the inactive plugins?
"Develop with Pleasure!"
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.
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.
"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.
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.
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.
"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> 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.
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 ;) ).
Another vote to support this. I use the R plugin for one project, but it activates features on a second one that get in the way.
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.