Join forces PMD

[rsoesemann]

Just stumbled over your great tool and wondered if it wouldn't make sense to port your rules (or even merge it partially) with PMD. Just recently @aidan-harding contributed code to make Flow rules possible.

• [xml] New language to detect issues in Salesforce Flow pmd/pmd#3413 [xml] New language to detect issues in Salesforce Flow
• [core] Support forcing a specific language from the command-line pmd/pmd#3417

What do you think? If contributing your Flow knowledge to #PMD sounds not crazy for you, ping me and I tell you how to do it.

[rsoesemann]

@RubenHalman I told @aidan-harding to connect with you on this. Let me know when I can help with anything.

[RubenHalman]

@aidan-harding

I'm having some difficulty grasping where you with the language based on the ticket and fork. Not sure if there's anything usable from this repo, but if you can fill me in Ill see where I can help!

[aidan-harding]

Hi @RubenHalman

Sorry for being fairly unresponsive on this. I've was all-in working on the PMD Flow language for a bit, but I've had other projects take away my time over the past month or so.

It would be great to get input on the rules when I've got my implementation ready to write some rules.

The current state in PMD is that 2 things were required to check Flow:

1. Some language detection changes so that PMD could support different languages with the same file extension. For this, I've made a small change to PMD. My change forces PMD to use the language you provide as a command-line argument instead of trying to match for itself. This was released in PMD and gives us enough for an MVP of Flow checking in PMD. The ideal would be something smarter so that you can point PMD at a directory tree with multiple languages and it could auto-detect across multiple languages. That was too big for me to take on initially, but it's tracked here [xml] Please externalize the mapping of file extensions to languages as preference file  pmd/pmd#461
2. A new PMD language module for Flow. Although Flow is stored in XML, the XML structure of the files doesn't represent the structure of the Flow directly. I imagine that your tool does the same thing of reading in the XML and building the Flow graph in memory so that you can do analysis on it. Since PMD already has support for easily writing rules against an AST for other languages, my intention is to translate the Flow into an AST. Then we can make use of the existing PMD tool for writing rules.

Once I get back and finish writing the Flow language module, I'll definitely look through your rules as an initial set of rules of PMD.

[RubenHalman]

@aidan-harding No worries, thank you for your reply. We all know how it goes=)

These are the same rules as from the standard help documentation.

I think I can help you help with the implementation of the language module?

[rsoesemann]

Any plan on when you continue your work @aidan-harding ?

[aidan-harding]

I have some notifications in my email about this thread, but the messages don't seem to be here any more.

My stance on this is that when I was working on this, I was at a consultancy where checking Flow was a live and important issue. Since then, I've changed role twice, and the importance of Flow in my mind has dropped hugely. So I don't think it's something I expect to pick up again.

I still think that XML-based rules in PMD are not enough to competently analyse Flows. I think the format of Flow's XML means that the structural rules you can write on them with XPATH don't say all the things you need to say. You can't properly say "no DML in a loop". You can say "no DML as a direct child of a loop", and maybe do some hacking around to make it go slightly further, but that's not really satisfactory to me.