Set up proper module system

[efritz]

Don't keep doing this ad-hoc catting of files.

[JoshuaSCochrane]

Hey @efritz I've been working with @tianzhao to get arrows working in node.js and originally tried targeting each file as a separate entity, but the dependencies got really wacky - I was playing games with when in a given file I'd export something and when I'd require something from something else so I'd know it was available, and it just got messy, so I switched to working on dist/arrows.js so almost everything is in the same file (still had to play one or two games with dist/parser.js that are hopefully reproducible with jison) and we could get a proof-of-concept and get something going (which we mostly do now, running some tests from the readme, which uncovered some bugs @tianzhao has relayed to you).

All that to say: I think if you want to properly modularize arrows, we'd need to figure out how to cleanly split and organize the dependencies. Maybe there's an app or something to draw a dependency graph for us?

[efritz]

So when I concatenate the files together I do it in this order:

https://github.com/efritz/arrows/blob/master/gulpfile.babel.js#L25

And aside from a few helper functions (which could be put in a common util file), the dependencies should only go forward. Things do get a bit weird, though (arrows, types, and the type checker all know about each other).

Not quite sure how to tackle this yet.

[JoshuaSCochrane]

Yeah, I saw the ordering in the old build script too. When I worked it out in dist/, I found that I had to move types & typechecker first (before arrows.js), export those classes, then require parser.js, which semi-circularly requires arrows.js to get at the types & typechecker parts then returns to arrows.js, which then has access to parser... Convoluted but it works. Maybe at this point I've learned a bit more about the library and could set up the requires without circular dependencies (or without quite as many - I think I had parser requiring arrows...), but I'll take a look at some point.

If you're interested, you can see most of my changes in my fork under the 'jsc-comments-questions' branch, particularly the latest commit 23fa9f2 where I tried to split out the parts that make dist/arrows.js node-capable - mostly just WIP and would be cleaned up before pushing any PRs back to mainline, and I don't really have a real use case/example for node.js yet, but it works with some of the examples culled from the readme, and the memory example continues to run (when modified to target this version instead of legacy of course).