Again, it literally says Compatible … so even if I had known about the verifier earlier, it would have read Compatible.
I’m down to 8 internals now though.
Compatible here only means binary-compatible and “can work” in IDE, while API usage violations still can be present. We may improve statuses for sure, but at the moment Compatible is about being de-facto compatible with IDE version.
Ok, I understand now. Thanks!
I think i’ve been able to replace most of the usage. Many were also repetitive calls so once replaced in one place, a lot of them disappeared.
I am targeting 253 and some also gets non internal in 261.
But looking at the output of the image that says compatible, there is no knowing right now that 8 usages of internal API are more problematic than the deprecated use for instance.
The verifier might need to be updated to inform better as you just mentioned.
Also, since its not valid code in your eyes, Jetbrains should consider wether the plugin should be allowed to launch at all or be installed so that developers gets into this workflow early on. But maybe the verifier and building wants to be separate for good reasons.
Unfortunately I haven’t been using Gradle due to some limitations on how to structure the code, and thus it was never as easy as running the gradle task I assume is there.
But I am getting close.
I hope the deprecated can be ok to leave behind for now, as only internal is red in the UI and I will work on getting off them too eventually but for now almost done with the internals.
As a Plugin Verifier contributor
- please please use it. Integrate it in your local builds, integrate it into CI/CD builds. Treat it as a Quality Gate.
Also: new plugins without any publication history or track record have a quite strict requirements. @Internal API is a blocker, with very granular exceptions.
As I see it, the local runs might be improved, regarding UI/UX, as it might not be obvious, that internals are a major issue while deprecateds are generally permissible.
47 is quite a lot. Im sure there are alternatives for a few of them, and for those that don’t, usually if the feature is not a core dangerous feature, you can negotiate to get accepted.
but that’s only if it’s one or two. Such a numerous amount of internal api is quite a no-go.
If you can’t find a replacement, can’t get an exception and can’t give up on the feature, then there is always the last option: publish your plugin outside of the marketplace. Developers have been using it for years to publish their apps out of the AppStore and I would even argue that it’s become quite the alternative with the democratization of brew.
Of course that would also mean that you’ll have to convince users that your plugin is not dubious since it’s not distributed in the regular ways, and you’ll have to do much more marketing (although this is not that big of a deal since the “featured” section of the marketplace is useless for newcomers anyway)