Repository navigation
Building from scratch is not simple yet #400
Description
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.
- if Core.js is missing, if yarn is missing, give error Yarn not found, install it here http://.....
- if Core.js is missing, if yarn is present, run make
Activity
bryanjos commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
@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 commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
Makefiles will not work on windows though. What about
mbu?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 commentedon Sep 12, 2017
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 commentedon Sep 12, 2017
@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 installandnpm run build.Also I did look at elixir_v8 before. May be good to experiment with it. Especially if #408 is implemented
OvermindDL1 commentedon Sep 12, 2017
Those are precisely the reasons that
mbuwas 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.