We have an internal system that binds YAML files to an equivalent Java interface, which is populated at runtime. Imagine the Spring Framework’s configuration annotation system if you’d like a more immediate reference. I’m trying to implement enhanced support for an “unused property” inspection.
When a method has an annotation binding it to the YAML file, and that method is marked as unused, is there a way I can either tell IntelliJ that the YAML property is also unused and able to be safely deleted?
Our plugin already has its own Safe Delete implementation that can handle this exact scenario, so ideally, I’d like to use that in place of the default Safe Delete path, but I understand if that’s not something possible in the current API.
As far as I know there is no unused symbols inspection for YAML, so the only way would be create a new inspection and implement such searches
Thanks Yuriy. That’s what I thought. Is there an event listener I can bind my plugin to for safe deletes, where I can then run my own Safe Delete check to see if any YAML properties are no longer in use?
Apologies for the slow response, I went on vacation a day after I posted this question.
You may want to check SafeDeleteProcessorDelegate extension and code.
For propagation logic you need SafeDeleteProcessorDelegate#getAdditionalElementsToDelete. There are some example implementations in intellij-community, e.g. JavaSafeDeleteProcessor.
As far as I understand there is a chance that if you put proper PSI references to YAML literals that point to Java classes/methods then Safe Delete in the platform will be able to take that into account automatically. But the propagation of delete targets needs additional work.
Ah yes! I already have that method implemented. However, my safe delete implementation is for the YAML side; I’m trying to figure out how to tie that implementation into the built-in Java safe delete functionality. I assume there’s no extension point for that yet, or if there is, it’s something much more complex and risky (like replacing the built-in Java safe delete class entirely).
I’m all good with telling our engineers that if they safe delete a property from the Java side, they have to check the YAML side for new safe delete results as well. No need for a new feature in the platform at this point to support such a niche use case, although it might be potentially nice for people storing config in the Spring Boot Config files to be able to remove a field and drop the entry if there’s no other uses.