Thanks for the quick reply.
I agree that intentionally making the JSON unreadable, or non-standard isn't a good outcome. Understanding JSON is a big issue for people new to using the notation for Objects and Arrays. Adding the complexity of a non-standard feature would render JSON reading and edit services unusable. I admit this would add confusion rather than improve Node-Red.
I take your point on separate JS files. I saw this contrib node in NPM when I went searching for answers, https://www.npmjs.com/package/node-red-contrib-file-function from 2015. I haven't tried to use it, because I was concerned it wouldn't "play nice" with the Projects feature. This seems like the basic approach you described in your reply. However, the obvious downside is this would eliminate the ability to simply have JSON portability where you can copy and paste a flow. This is a pretty basic part of the Node Red culture that would be lost, or at least complicated.
I read an article recently on solving this kind of multi-line problem with JSON using an array with strings. https://www.gun.io/blog/multi-line-strings-in-json
I was thinking that this might be the answer. So instead of trying to alter the JSON in flows_*.json we work with it, and replace {"func" : "code"}with {"func" : ["line of code 1", "line of code 2", "line of code 3"]}.
Then the existing PrettyPrint would render it as:
In this way Node-Red could ensure compliance with the existing JSON standards and add the capability to version control a function. Generally all "func" properties could be put inside an array, even if there was only one line of code.
I assume this might impact the core processor a bit for Function nodes, but it seems like it would fit in with the rest of the existing Node-Red code base.
