Add support for running and importing compiled elm programs from node

[ajhager]

This PR adds minimal support for running and importing compiled elm programs from node. I am working on a package, elm-node, that adds a standard library for server side programs (with a hack to make it work in the mean time), but these simple changes should add native support.

In summary it changes window.Date to Date in two modules that make sense to be used from node. It also detects if the script is being used within node, exporting the Elm object as its module if it is being imported from another script, or automatically executing the Main module in an Elm worker if it is being directly run.

var Elm = require("./elm.js");

Elm.worker(Elm.MyModule, {});

$ node elm.js

[evancz]

Sounds like the Date part will fix elm-lang/elm-repl#70 right?

Do you mind splitting this into two PRs? I'm definitely down with the date fix. I have been looking at getting things going on node and had a different approach for that. I'm traveling this weekend, but I want to understand that better before doing the approach here.

[evancz]

Sounds like the Date part will fix elm-lang/elm-repl#70 right?

Do you mind splitting this into two PRs? I'm definitely down with the date fix. I have been looking at getting things going on node and had a different approach for that. I'm traveling this weekend, but I want to understand that better before doing the approach here.

[ajhager]

The Date / Time fix is in #320.

And no hurry on the node support part. Like I said, the fix is already in the elm-node library. I just wanted to start a dialog about it.

[ajhager]

The Date / Time fix is in #320.

And no hurry on the node support part. Like I said, the fix is already in the elm-node library. I just wanted to start a dialog about it.

[evancz]

With the upcoming dead code elimination (DCE) the JS output of elm-make is going to be changing pretty dramatically. The plan is for there to be no true module boundaries, and you will only be able to initialize certain modules like this:

Elm.fullscreen('Main')

So we will no longer be adding a bunch of stuff to the global Elm object that you have to know about. This means:

• we will be able to give better errors when you misspell the module
• we can expose only the modules you actually compiled with elm-make instead of all the dependencies

This also means that the node support should probably just export fullscreen, embed, and worker. Now that I write it down, maybe it only should export worker.

That is what I had in mind at least. Does that API make sense?

[evancz]

With the upcoming dead code elimination (DCE) the JS output of elm-make is going to be changing pretty dramatically. The plan is for there to be no true module boundaries, and you will only be able to initialize certain modules like this:

Elm.fullscreen('Main')

So we will no longer be adding a bunch of stuff to the global Elm object that you have to know about. This means:

• we will be able to give better errors when you misspell the module
• we can expose only the modules you actually compiled with elm-make instead of all the dependencies

This also means that the node support should probably just export fullscreen, embed, and worker. Now that I write it down, maybe it only should export worker.

That is what I had in mind at least. Does that API make sense?

[evancz]

Ah, if we have elm-make generate the code needed for node, we can actually make initialization even simpler. Like, only export the exact modules that can be created as a function. How does this change your idea here?

[evancz]

Ah, if we have elm-make generate the code needed for node, we can actually make initialization even simpler. Like, only export the exact modules that can be created as a function. How does this change your idea here?

[ajhager]

Yeah, all of that sounds great. There are two features that I see as important.

1. Export an object or function that allows you to import an elm js file as a module, setup ports, and start a worker.
2. Some convention that allows you to run an elm.js file automatically.

It looks like you have some great ideas about doing 1. And my code handles number 2 by checking that if you have a Main module, and the code is being run directly (not being imported as a module,) start a worker with Main.

Number 2 is important so we don't need to append wrapper scripts like elm-io-ports.sh to every file.

[ajhager]

Yeah, all of that sounds great. There are two features that I see as important.

1. Export an object or function that allows you to import an elm js file as a module, setup ports, and start a worker.
2. Some convention that allows you to run an elm.js file automatically.

It looks like you have some great ideas about doing 1. And my code handles number 2 by checking that if you have a Main module, and the code is being run directly (not being imported as a module,) start a worker with Main.

Number 2 is important so we don't need to append wrapper scripts like elm-io-ports.sh to every file.

[evancz]

I think it's a bit odd to require that the module you want to run is named Main. What if you want to run different files that happen to be in the same directory? Also, how does this work with elm-make Cats.elm --output=index.html? IIRC, it generates fullscreen(Elm.Cats) which I think would be simpler for folks.

[evancz]

I think it's a bit odd to require that the module you want to run is named Main. What if you want to run different files that happen to be in the same directory? Also, how does this work with elm-make Cats.elm --output=index.html? IIRC, it generates fullscreen(Elm.Cats) which I think would be simpler for folks.

[ajhager]

Oh yeah, absolutely. I didn't have the information available in the Runtime, so the 'Main module' convention was just a hack. With elm-make handling things, I definitely like your idea better.

[ajhager]

Oh yeah, absolutely. I didn't have the information available in the Runtime, so the 'Main module' convention was just a hack. With elm-make handling things, I definitely like your idea better.

[evancz]

Okay, cool, let's try to retarget this improvement to elm-make then?

P.S. Trying the aggressive closing of issues. Really want to support this case, so if we find problems with doing this in elm-make let's revisit things here :)

[evancz]

Okay, cool, let's try to retarget this improvement to elm-make then?

P.S. Trying the aggressive closing of issues. Really want to support this case, so if we find problems with doing this in elm-make let's revisit things here :)

[evancz]

I had played with adding an extra line to this code. Not sure exactly what it should say there, but that'd be my guess of where to anchor this change.

[evancz]

I had played with adding an extra line to this code. Not sure exactly what it should say there, but that'd be my guess of where to anchor this change.

[evancz]

Also, I'm realizing that I kind of just said "go look at a decently complex Haskell project" which maybe is a crazy thing to do. We can also continue figuring out what the ideal API would be and what that'd need from the Runtime.js file, save the elm-make stuff for later.

[evancz]

Also, I'm realizing that I kind of just said "go look at a decently complex Haskell project" which maybe is a crazy thing to do. We can also continue figuring out what the ideal API would be and what that'd need from the Runtime.js file, save the elm-make stuff for later.