I use closure compiler version v20171203 with
--compilation_level SIMPLE_OPTIMIZATIONS It gives a few warnings but works fine. Newer versions can’t process my code and output errors. Note that SIMPLE_OPTIMIZATIONS doesn’t remove dead code.
uglifyjs or, if you don’t want to bother with the options, use
elm-minify (which uses
uglifyjs behind the scene).
uglifyjs elm.js --compress 'pure_funcs="F2,F3,F4,F5,F6,F7,F8,F9,A2,A3,A4,A5,A6,A7,A8,A9",pure_getters,keep_fargs=false,unsafe_comps,unsafe' | uglifyjs --mangle --output=elm.min.js
elm-minify and it worked fine. The concept of Prepack is different than minification or dead-code-removal (which Google Closure Compiler does). It eliminate computations which can be done on compile time, so the app runs faster during runtime (having to deal with less computations). Google Closure compiler may also be doing something similar when the “advanced” option is chosen (I’m not sure about that).
Though it’s not necessary, but I thought if somebody already did it, getting the benefits for free is a good thing.
Out of curiosity, I tried using
prepack on a simple Counter app. It worked in that it produced some
.js file that behaved properly. The funny thing is that
elm-minify on the prepack version produced a large minified version than running it on the compiler output.
Main.elm > compiler > prepack > uglifyjs produces a file that is larger than
Main.elm > compiler > uglifyjs.
I have tested it on the
elm-spa-example and the difference remains. (93k for the uglifyjs only vs 114k for prepack + uglifyjs)
It would be wonderful to have compile time function evaluation native in the elm compiler when the
--optimize would be used. This would allow for even smaller sizes but it is not a trivial optimization.
Not necessarily. I imagine that a restricted version of this functionality could be implemented without going through JS. Imagine implementing an
eval function that would be able to evaluate some Elm code by using Haskell’s functions. It might not be able to evaluate every piece of Elm code but it doesn’t need to. The compile time execution can be provided for a restricted set of elm functions and ignored for what it cannot do. For example, it can provide execution of operations on
String and maybe on very simple custom types.
In any case, it would not be trivial and I’m not familiar with the compiler implementation so I might be talking nonsense.
I believe that prepack targets speed of execution and initial parse/execution optimizations so it is like an optimizing compiler, rather than a minifier.
Then I wonder what it would do with the js equivalent of:
range : List Int range = List.range 0 42000
Would it pre-compute it?
If it is in the top level and run on the first pass, then yes. See example
We use the google closure compiler with great success for Elm 0.18! We run it using the
webpack-closure-compiler for webpack, but only for production builds (for speed reasons).
But you do need the correct version of Java installed locally for it to work correctly–the JDK.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.