Improvement: Disable errorprone in intellij #2010
Conversation
|
I think this would probably be net positive, but just trying to consider possible downsides:
One alternative might be downgrade things from error->warning or even info in IntelliJ? |
| public final class IntellijSupport { | ||
| private static final String INTELLIJ_ACTIVE = "idea.active"; | ||
|
|
||
| public static boolean isRunningInIntellij() { |
There was a problem hiding this comment.
Mind consolidating the idea.active checks from BaselineIdea as well?
Does this actually happen? I didn't think idea picked up error-prone warnings, but most of the projects I work on fail in that case, so I may not have seen it. If so, I'd be down for opting out of Re caching: It's unfortunate to lose gradle caching, but it's a bit difficult to prototype things with StrictUnusedVariable enabled, so I think the trade-off makes sense. |
|
Yeah StrictUnusedVariable is savage. 👍 from me. |
|
I don't believe that intellij shows squiggly for errorprone OOTB |
|
Released 4.48.0 |
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.47.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Gradle plugins don't enforce PublicConstructorForAbstractClass which can break gradle injection | palantir/gradle-baseline#2009 | ## 4.48.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Disable errorprone in intellij | palantir/gradle-baseline#2010 | ## 4.49.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Allow projects to override library auto-detection | palantir/gradle-baseline#2011 | ## 4.50.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Improve coordination between java-versions and idea ipr allowing project iprs to be successfully imported | palantir/gradle-baseline#2012 | To enable or disable this check, please contact the maintainers of Excavator.
|
While I understand the motivation for this change, it breaks what is, IMO, one of the biggest benefits of using the native Gradle integration - shared build infrastructure and caching. When switching between my IDE and the command line, I now need to compile everything twice. In my experience, being able to avoid expensive recompilations is far more valuable that avoiding error-prone warnings when iterating. |
|
I'm also not convinced that disabling error-prone is the correct tradeoff. It can be very confusing if my code doesn't pass CI due to an error I cannot see when I build locally. It now becomes very time-consuming to get passing CI build, especially if I have errors in multiple projects that depend on each other transitively because I will only see one error at a time. Avoiding this requires knowing that compiling on the command line will show these errors. I would much rather know that my code won't pass CI before I push (since I'm almost certainly compiling locally anyways) instead of pushing thinking it's good, and then finding out 5-10 minutes later than it was not good. |
|
At the very least, I'd appreciate if we gave devs an option to avoid this "feature". AFAICT there's no way for me to prevent IntelliJ from setting the |
Before this PR
Running test/compilation from intellij with gradle integration was pretty painful since it would cause all errorprone rules to run. This slowed down overall compilation but also made it hard for you to quickly iterate on a test, or hack together a proof of concept
After this PR
==COMMIT_MSG==
Disable errorprone in intellij
==COMMIT_MSG==
This will not impact CI in any way and should only make the gradle integration's behaviour closer to working with a
*iprfilecc @iamdanfox
Possible downsides?