Implement Tree Shaking in LiveScript

[JoyKrishnaMondal]

I have been thinking about dead code elimination and Tree Shaking.

Since LS compiles to ES5, its not atm possible to implement Tree Shaking :(

Thoughts ?

[JoyKrishnaMondal]

it should be possible to do tree shaking since in ls we can do nice imports like this:

{foo,bar} = require 'lib'

[robotlolita]

Tree shaking requires both whole-program compilation and some way of both figuring out all of the dependencies statically (without running the code). This is "dependencies between program entities" more than just "what something imports". The LiveScript compiler does modular compilation, so it can't really do tree shaking.

[JoyKrishnaMondal]

So it has to be a separate transformation process ?

PureScript has a cool Tree Shaking algorithm built into pulp and so is ES6 with RollUp - just thinking that we should not be left behind.

[JoyKrishnaMondal]

RollUp does it with ES6 syntax - but that type of import is also present in LS :D so it means theoretically it should be possible to do it for ls

[AriaMinaei]

This probably would be trivial if we did this.

ps. I wish I had time to work on it, but I don't. It would be great if someone could pick it up. Once a basic atchitecture is set up, others can collaborate on the details and edge cases.

[robotlolita]

@JoyKrishnaMondal it's more about semantics than syntax, although the syntax helps.

First thing you need to be able to do tree shaking is whole-program optimisation, though. This means LiveScript's compiler would have to stop doing modular compilation. IOW, instead of:

lsc < moduleA.ls > moduleB.js
lsc < moduleB.ls > moduleB.js

You'd need:

lsc < program.ls > program.js

So the lsc command would have to work on the whole program, following all things imported by that program and figuring out what should and what shouldn't be included in the final bundle. The LiveScript compiler doesn't do this right now, and this would be a major architectural change with how the compiler is structured right now.

I'm not sure it's worth it, though. A better approach would be generating ES6 modules and just letting people post-process it with Rollup. This way you get to keep modular compilation (less changes to make), and still get the optimisation if you want. This might require changing the module system to not allow importing of regular CommonJS modules, though, since you can't do tree shaking on those.

[JoyKrishnaMondal]

@robotlolita makes sense - but for now LS only compiles to CommonJS rather than ES6.

I am thinking Tree Shaking is overblown if it cannot do CommonJS optimization. Better to use Google Closure Compiler and let things stabilize.