Official support for elm-optimize-level-2

[robinheghan]

We currently use elm-optimize-level-2 with this vite plugin using the trick described in #2

We quite rely on elm-optimize-level-2 for our application to run efficiently, but we'd also like to enable eol2's --optimize-speed flag, which isn't possible the way things are now.

Would you consider adding official support for elm-optimize-level-2 to this plugin, with the option to pass additional flags?

[hmsk]

Thanks for raising it up! I totally missed about some unique options are available for eol2.
I would like to let the plugin support eol2 as first-class like:

elmPlugin({ compiler: { path: 'path-to-eol2', flags: { optimizeSpeed: true } })
elmPlugin({ elmOptimizeLevel2: { optimizeSpeed: true } })

but that needs me to take an extra time to look into eol2 command and to take a cost of deciding API which can't be easily changed without major update. So my current will is having an unrestrained but flexible option like:

elmPlugin({ compilationCommand: '/path-to-eol2 --optimize-speed' })

to unblock eol2 users earlier than I stuck on doodling API specs.

[robinheghan]

Thank you for getting back to me so quickly! The compilationCommand option would work for me. I was actually looking for that initially, before raising an issue.

[hmsk]

Introduced compiler.command option and pre-released it as v3.1.0-0. npm run build:eol2 in /example is an actual working sample. ⚠️ This plugin's features (vite assets, combining build) won't work since eol2 mutates the original compiled code.

The API may undergo changes (such as the method of capturing stdout, which currently appears a bit odd) until the official release. However, this should unblock you for now. Please give it a try and provide feedback.

During the process of building this feature, I gained a better understanding of eol2 and learned that it's not actively maintained. As a result, I'm now inclined towards incorporating optimization methods within this plugin, including those offered by eol2.

[hmsk]

After releasing it, I'm considering replacing the option with just compile: (targets: string) => string to accept arbitrary compilation results instead of capturing stdout.

[robinheghan]

I just tried using this, but got the following error:

Cannot create property 'code' on string 'Failed to run command: RangeError [ERR_CHILD_PROCESS_STDIO_MAXBUFFER]: stdout maxBuffer length exceeded '

[hmsk]

Oops, yeah, it proves taking stdout was a wrong approach 😂 will update to compile: (targets: string) => string soon. Thanks for trying it out quickly!

[hmsk]

Released the change as v3.1.0-1

Replaced the previous compiler.command with compiler.compile: (targets: string[]) => Promise<string>. https://github.com/hmsk/vite-plugin-elm/blob/main/example/vite.config.ts