While minifying modules currently the Google closure compiler will be used with SIMPLE optimization (=default without the @compilation_level ADVANCED_OPTIMIZATIONS annotation).
There is still a little imperfection already stated: The basic rule is refer to anything you don't want minified as an indirect property reference, so me.property should be written as me['property'].
This blights the code a little bit and can be avoided be giving the closure compiler the knowledge which code you want to keep. Moray already mentioned the "extern" approach http://forum.espruino.com/comments/12636552/. A simple usage scenario (without parameters) would be enough. Here is an example of the HTU21D module:
var htu = exports.connect( null );
var t1 = htu.RH_12_BITS_TEMP_14_BITS;
var t2 = htu.RH_8_BITS_TEMP_12_BITS;
var t3 = htu.RH_10_BITS_TEMP_13_BITS;
var t4 = htu.RH_11_BITS_TEMP_11_BITS;
htu.isMeasuring();
htu.readTemperature();
htu.getTemperature( null );
htu.readHumidity();
htu.getHumidity();
htu.getCompensatedHumidity( null, null );
htu.getDewPoint( null, null );
htu.softReset();
htu.getResolution();
htu.setResolution( null );
htu.isEndOfBattery();
htu.isHeaterOn();
htu.setHeaterOn( null );
htu.getSerialNumber();
Now you can leave all the module code and advanced optimization works fine. But from where should we take this usage code for every module?
Write it manually
Extract it from the code annotations
Google itself has an @export notation but then you have to use the Google Closure Library → not applicable.
Parse/Grep would be possible but it's a lot of work until reaching a stable version for all possible cases.
Using a precompiler like TypeScript. Type information is available and it's seems Google is enhancing the minifier with some TypeScript support. For me this is the most promising option because I write modules in TypeScript and the advantage of using TypeScript at all is huge. But I think many module developers do not share this opinion - up to now. We'll see us in one year. ;-) But there is currently no out-of-the-box solution.
Currently I prefer 1) because it's straightforward and easy realizable and additionally leaves option 2) and 3) open.
Later it would be possible to enable advanced optimization in the IDE. This would be really great to remove all unused code during save().
What do you think about adding a simple extern/usage file for every module and compile the modules with advanced optimization? This would not be a huge one-step-solution. Every module can decide by itself:
Code sizes shrink about 30% to 40% when switching from simple to advanced optimization.
BTW: The Google webservice is slow with ADVANCED_OPTIMIZATIONS and denied after using too often. I wrote a local build script. It uses exactly the same directory/file convention so no customization is required. It's faster and no additional installation except Java is required (Google Closure Compiler is a Java program). I would make it available if somebody is interested...
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
While minifying modules currently the Google closure compiler will be used with SIMPLE optimization (=default without the @compilation_level ADVANCED_OPTIMIZATIONS annotation).
Moray gave an example of using advance optimization while he was refactoring the BME module. → http://forum.espruino.com/conversations/277165/
There is still a little imperfection already stated: The basic rule is refer to anything you don't want minified as an indirect property reference, so me.property should be written as me['property'].
This blights the code a little bit and can be avoided be giving the closure compiler the knowledge which code you want to keep. Moray already mentioned the "extern" approach http://forum.espruino.com/comments/12636552/. A simple usage scenario (without parameters) would be enough. Here is an example of the HTU21D module:
Now you can leave all the module code and advanced optimization works fine. But from where should we take this usage code for every module?
Google itself has an @export notation but then you have to use the Google Closure Library → not applicable.
Parse/Grep would be possible but it's a lot of work until reaching a stable version for all possible cases.
Currently I prefer 1) because it's straightforward and easy realizable and additionally leaves option 2) and 3) open.
Later it would be possible to enable advanced optimization in the IDE. This would be really great to remove all unused code during
save()
.What do you think about adding a simple extern/usage file for every module and compile the modules with advanced optimization? This would not be a huge one-step-solution. Every module can decide by itself:
A few numbers for the motivation behind:
Code sizes shrink about 30% to 40% when switching from simple to advanced optimization.
BTW: The Google webservice is slow with ADVANCED_OPTIMIZATIONS and denied after using too often. I wrote a local build script. It uses exactly the same directory/file convention so no customization is required. It's faster and no additional installation except Java is required (Google Closure Compiler is a Java program). I would make it available if somebody is interested...
And that could be the roadmap:
Any thoughts?