[IDEA] Script Preprocessor

[MichaelLeeHobbs]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

A script preprocessor that receives the the script string from the generateScript in server/src/com/mirth/connect/server/builders/JavaScriptBuilder.java and returns a modified/processed script for generateScript to use as the transformer source.

Describe your use case
I need this feature so I can accomplish .

This would enable adding missing JS features for example Template literal.

Describe the solution you'd like
A clear and concise description of what you want to happen.

I think the easiest way to do this would be to add a Edit Script Preprocessor between Edit Filter and Edit Transformer. It may even be desirable to have this as a flag in the server config to enable/disable this and have it disabled by default as it would be a very advance feature.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Alternative solutions are ugly. You can in theory run script through something like Babel.js before loading them into mirth.

Additional context
Add any other context or screenshots about the feature request here.

Would need to run scripts through the preprocessor before checking the script is valid. May even be desirable to disable the linter in the editor if someone is using the preprocessor. By adding this feature Mirth would effectively enable the community to add missing JS functionality that cannot be added via polyfills. I understand there are many places where scripts are used besides source/destination transformers but I would start with those two as a proof of concept.

[cturczynskyj]

Hello @MichaelLeeHobbs, could you add some detail as to why you need/want this? A specific example would be great! Are you trying to insert JS features that, currently, are not supported in RHINO?

[MichaelLeeHobbs]

Are you trying to insert JS features that, currently, are not supported in RHINO?

That is correct. There are other possible use cases but that is the primary.

[ChristopherSchultz]

I place stuff like this into the global script. The only thing I have right now is adding prototypes for Array.includes and String.startsWith.

Would this work for you, or is it important to be able to do this at an individual channel-level?

[MichaelLeeHobbs]

@ChristopherSchultz first your method cannot handle literals ie

var a = `some test ${val}` 

secondly if you are doing your polyfils that way then they are incorrect. Take a look at https://gist.github.com/MichaelLeeHobbs/8888395f6ada28df992aadeff92d074f

[ChristopherSchultz]

My polyfills look like yours. How exactly am I doing it wrong?

[MichaelLeeHobbs]

@ChristopherSchultz You showed String.startsWith not String.prototype.startsWith which is why I brought it up.

[ChristopherSchultz]

@MichaelLeeHobbs Well... I'm prototyping String.startsWith, not String.prototype.startsWith, which is why I said it that way. Apologies for the noise.

[MichaelLeeHobbs]

String.startsWith = function() {...} // creates a static method and will break on new String

String.prototype.startsWith = function() {...} // creates a method prototype that does not break on new String

Just to be clear

[tonygermano]

This is getting way off topic. I believe the intention of the request was to be able to use syntax which will not compile under Rhino, which could then be transpiled to javascript that would work in Rhino. Rhino's ES6+ coverage is very spotty (but improving,) but the ES5 coverage is really good. Many of the ES6 built-in Objects are working, but the syntax changes are very slow to get implemented.

[thorst]

I like this, but would vote to allow it to be applied to the filter as well. We dont use transformers and instead do all our coding in 1 js filter, so all the code is in one spot.