Emit compiled JS to stdout #39

Closed
rtfeldman opened this Issue Aug 5, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@rtfeldman

(Moved from elm/compiler#961)

Right now it's a bit annoying to build Elm integrations because the compiler can only write to files. When we want the compiled JS to be immediately consumed elsewhere (e.g. by Sprockets or Node), we end up writing a temporary file, reading it in, and then deleting it afterwards.

It would be cleaner if we could instead just consume the output directly and send it along to the next process in the pipeline, without having to deal with a throwaway file along the way.

Something like an --output-to-stdout flag would be great!

@texastoland

This comment has been minimized.

Show comment
Hide comment
@texastoland

texastoland Aug 8, 2015

I would prefer stdout be the default and --output write to file (the current default is unintuitive to me). The Sublime plugin currently relies on Richard's tempfile hack. But this could further complicate parsing JSON unless #38 is addressed first.

I would prefer stdout be the default and --output write to file (the current default is unintuitive to me). The Sublime plugin currently relies on Richard's tempfile hack. But this could further complicate parsing JSON unless #38 is addressed first.

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Aug 19, 2015

Contributor

What do other compilers do for this case? How is this done in clang or gcc or others?

Contributor

evancz commented Aug 19, 2015

What do other compilers do for this case? How is this done in clang or gcc or others?

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Sep 17, 2015

Contributor

We decided offline not to go for this. Rough reasoning is: it's not worth it to make the command line interface so much fancier. It will hurt beginners and help experts, but experts can do what they need to do anyway.

Contributor

evancz commented Sep 17, 2015

We decided offline not to go for this. Rough reasoning is: it's not worth it to make the command line interface so much fancier. It will hurt beginners and help experts, but experts can do what they need to do anyway.

@evancz evancz closed this Sep 17, 2015

@glenjamin

This comment has been minimized.

Show comment
Hide comment
@glenjamin

glenjamin May 8, 2016

I was about to raise this as a new issue, but spotted this one.

Is the book closed completely on this? I think it's possible without complicating the command line interface much. As it stands, "Experts" have to mess around with tempfiles, which makes things like streaming output much harder.

This could be something along the lines of a --stdout flag which would send all the output that way. To keep things straightforward I would suggest also keeping the existing --output flag, and it's extension detection stuff.

eg.

# Generate JS file
elm-make Main.elm --output=elm.js

# Generate JS file on stdout
elm-make Main.elm --output=elm.js --stdout

# Generate HTML file on stdout
elm-make Main.elm --output=index.html --stdout

To make this work, all other informational output would need to be on stderr. This would also make the /dev/null special case unnecessary.

I was about to raise this as a new issue, but spotted this one.

Is the book closed completely on this? I think it's possible without complicating the command line interface much. As it stands, "Experts" have to mess around with tempfiles, which makes things like streaming output much harder.

This could be something along the lines of a --stdout flag which would send all the output that way. To keep things straightforward I would suggest also keeping the existing --output flag, and it's extension detection stuff.

eg.

# Generate JS file
elm-make Main.elm --output=elm.js

# Generate JS file on stdout
elm-make Main.elm --output=elm.js --stdout

# Generate HTML file on stdout
elm-make Main.elm --output=index.html --stdout

To make this work, all other informational output would need to be on stderr. This would also make the /dev/null special case unnecessary.

@cuducos

This comment has been minimized.

Show comment
Hide comment
@cuducos

cuducos Jun 16, 2016

Issue closed, but I felt like agreeing with arguably diametrically opposed views on that.

Totally agree with @rtfeldman on this part, I just did exactly that here:

When we want the compiled JS to be immediately consumed elsewhere (e.g. by Sprockets or Node), we end up writing a temporary file, reading it in, and then deleting it afterwards.

And IMHO the --stdout suggested by @glenjamin seems to fit beginners and experts' needs.

But I do agree with @evancz:

experts can do what they need to do anyway

So the only thing unclear here is: is that a matter of prioritizing other things or, is this issue/request closed for good, declined for good? (I really don't want to go all over the arguments you probably had offline — I trust you guys — but just asking to decide upon the architecture of future deploy environments).

cuducos commented Jun 16, 2016

Issue closed, but I felt like agreeing with arguably diametrically opposed views on that.

Totally agree with @rtfeldman on this part, I just did exactly that here:

When we want the compiled JS to be immediately consumed elsewhere (e.g. by Sprockets or Node), we end up writing a temporary file, reading it in, and then deleting it afterwards.

And IMHO the --stdout suggested by @glenjamin seems to fit beginners and experts' needs.

But I do agree with @evancz:

experts can do what they need to do anyway

So the only thing unclear here is: is that a matter of prioritizing other things or, is this issue/request closed for good, declined for good? (I really don't want to go all over the arguments you probably had offline — I trust you guys — but just asking to decide upon the architecture of future deploy environments).

@mrozbarry

This comment has been minimized.

Show comment
Hide comment
@mrozbarry

mrozbarry Feb 14, 2017

Just to pipe in to this, I'm in the planning stage of writing a server-side compiler for an online elm sandbox tool, and being able to pipe elm-make directly to a client rather than a temp file makes way more sense, and is allowed on way more free webhost platforms (where npm can install, but I may not be able to create tmp files).

I'm perfectly happy with a --stdout flag, as it means it's extra work to go against the grain, and it resolves use cases described above plus my own.

Just to pipe in to this, I'm in the planning stage of writing a server-side compiler for an online elm sandbox tool, and being able to pipe elm-make directly to a client rather than a temp file makes way more sense, and is allowed on way more free webhost platforms (where npm can install, but I may not be able to create tmp files).

I'm perfectly happy with a --stdout flag, as it means it's extra work to go against the grain, and it resolves use cases described above plus my own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment