Building from scratch is not simple yet

[vans163]

We still cannot include elixirscript from github into a project. Running mix deps.get && mix compile does not build the initial Core.js. We need to clone elixirscript, make, then use elixirscript via path in our mix.exs.

I am proposing to integrate 2 features here when doing mix compile.

1. if Core.js is missing, if yarn is missing, give error Yarn not found, install it here http://.....
2. if Core.js is missing, if yarn is present, run make

[bryanjos]

I'm not sure about this one. I definitely want to do things the right way. I may ask on IRC, the Elixir Forum or both to find the right way to handle this

[OvermindDL1]

Well as me, I definitely do not want yarn to be a requirement. ^.^;

NPM is 'acceptable' but would prefer not to have it as well.

Thus pre-baking core.js into the git repo and distributions is what I'd vote for. A pre-commit hook would even work.

[OvermindDL1]

Oh, and definitely want ES6 output if possible rather than a single entire core javascript, much easier and more reliable to tree shake than considering all the indirect calls.

[vans163]

@OvermindDL1 tracking the core.js makes no sense though, since it has no editable source code itself and its a product of compilation. It kind of makes sense to ship it in a release, perhaps on hex?

Breaking up the output to 1 ES6 per beam file would definitely help in the caching modules case. With a way to weave them all together. The problem with this is elixirscript currently discards unused functions, so making separate modules might not function as you would expect. Like most of Enum might be missing once it transcompiles into ES6.

I think its a solid bet to transcompile every function available in development builds, and in release builds run the final ES6 under a minifier/unused-code-remover.

Perhaps certain beam files could be blacklisted, like the unicode library, and replaced with elixirscript shimmed versions.

@bryanjos It should be possible to use :os.cmd("make") from inside mix compile. Leveraging the code related to finding the applications root dir (often seen in nif on_load functions).

[bryanjos]

Focusing on the specific issue here. This only effects projects that include ElixirScript from git. Any solution should effect only that case. I have no problem with including it in source control. It does make PRs slightly annoying but not by a lot. If make is the solution then I agree with @OvermindDL1 that yarn should not be a requirement. npm and node should be the only requirements. Instead of coming up with some homegrown solution, I would prefer elixir_make if this is the decision

[bryanjos]

For the output, please make another issue for that. The output is already in ES module format. Splitting out each module per file will probably be a large task. And one incompatible with any bundling that's done in ElixirScript. These are the times I wish Erlang/Elixir had a JavaScript engine available to it.

edit: I created #408

[OvermindDL1]

Makefiles will not work on windows though. What about mbu?

These are the times I wish Erlang/Elixir had a JavaScript engine available to it.

There are V8 bindings somewhere I remember in the erlang ecosystem.

EDIT: And one in the elixir ecosystem too now apparently: https://hex.pm/packages/elixir_v8

[vans163]

The makefile does not do much except proxy some commands. It can be substituted by a few extra calls to :os.cmd/1. Assuming path is correctly set, building core.js would be windows/linux/mac agnostic.

Isnt yarn a replacement for npm? IMO yarn > npm based on the design decisions behind yarn. But either yarn or npm then node as a requirement makes sense to me, I do not see why npm has to be a hard requirement.

[bryanjos]

@vans163 @OvermindDL1 I would almost rather have a mix task that built it. It doesn't have to be ran more than once. Only things that should need to be run are npm install and npm run build.

Also I did look at elixir_v8 before. May be good to experiment with it. Especially if #408 is implemented

[OvermindDL1]

I would almost rather have a mix task that built it. It doesn't have to be ran more than once. Only things that should need to be run are npm install and npm run build.

Those are precisely the reasons that mbu was originally made. It is a builder for mix tasks to do 'stuff', and things like interacting with npm for such commands was its original goal before it become even more generic.