Skip to content
This repository has been archived by the owner on Aug 23, 2018. It is now read-only.

Friendlier elm-make interface for beginners #23

Open
4 of 10 tasks
laszlopandy opened this issue Jun 19, 2015 · 12 comments
Open
4 of 10 tasks

Friendlier elm-make interface for beginners #23

laszlopandy opened this issue Jun 19, 2015 · 12 comments
Labels

Comments

@laszlopandy
Copy link
Member

laszlopandy commented Jun 19, 2015

For end users (not creating a library)

  1. $ elm make (no arguments)
    • if no elm-package.json or *.elm, print: No elm project found, should one be created?
      • create hello world Main.elm and default elm-package.json
    • if *.elm exists, print: No elm-package.json was found, should one be created? (y/n)
      • create elm-package.json
    • if *.elm and elm-package.json exist, print: Error: Please specify a main .elm file
  2. $ elm make Main.elm
    • install dependencies found in elm-package.json
    • compile Main.elm, and all modules it depends on
    • write concatenated Html output to index.html
  3. $ elm make Main.elm -o elm.js
    • write concatenated output to elm.js
  4. $ elm make Main.elm -o mypage.html
    • wrap JS output in HTML and write to mypage.html
  5. $ elm make Main.elm --node-js -o node-test.js
    • writes JS output and adds Elm.worker(Elm.Main); to the end to start the app in NodeJS
  6. $ elm make X.elm --node-js -o node.html
    • Error: output file must end in .js when --node-js is used.
  7. $ elm make X.elm -o page.htm
    • Error: output file must end in either .js or .html

For library creators

TODO

@laszlopandy
Copy link
Member Author

The above is my suggestion for how elm make can be easier for beginners. Please add your comments, especially about the part for library creators (which I have no experience with). Once there is agreement, we can start the implementation.

@evancz
Copy link
Contributor

evancz commented Aug 19, 2015

I am going to try to do this in the next couple days. I like it. I think we can combine the --node-js and --js flags into one thing, but otherwise I think this is way nicer!

@texastoland
Copy link

Feedback based on the Sublime plugin:

  • I save the main file in elm-package.json under a sublime-build.main key. It's necessary to be able to compile a given project from another file. It also seems necessary to auto-build arbitrary projects.
  • Our output path would be inferred as build/Main.html instead of index.html. It's not as pretty but prevents accidentally blowing away a separate compilation.

@evancz
Copy link
Contributor

evancz commented Aug 20, 2015

I can't understand either of these points. Can you move this to its own issue and describe your scenario more completely? I don't know how sublime works, I don't know what you are asking for or how it relates to any of the very concrete suggestions made in this thread.

@texastoland
Copy link

The latter point is more concrete:

write concatenated output to index.html

The default we use is build/Main.html. If you then run elm make Counter.elm it wouldn't blow away your previous output.

The former point might belong in a separate thread. It's difficult for us to infer what file to build. It seems like a main key in elm-package.json would not only benefit tooling but concepts like an auto-building gallery repo. I brought it up because it's relevant to the proposed interface.

@texastoland
Copy link

It seems like a main key in elm-package.json

I.e. elm make would check for main in elm-package.json and elm make Counter.elm would override that key.

@evancz
Copy link
Contributor

evancz commented Aug 20, 2015

Please open another issue.

evancz pushed a commit that referenced this issue Aug 21, 2015
Start a refactor to better organize the code in this repo. This change
also begins addressing error reporting stuff described in #23, #47, and
#46. It also adds rudimentary timing information so we know how long
different phases take.
@laszlopandy
Copy link
Member Author

@evancz I've changed my mind regarding the --js and --html. I think having --html, --js and --node-js is too much, especially since they cannot be used at the same time.

Instead I think we should:

  • make it clear in the --help message that HTML, JS and NodeJS outputs are supported
  • keep the current situation where the output filename determines the output type but add an error if the user uses any extension except .js or .html. This will prevent the confusion when using .htm or something else.
  • add a --node-js option which gives an error if the output filename does not end in .js.

Let's talk about this at the meeting later.

@evancz
Copy link
Contributor

evancz commented Sep 24, 2015

@seliopou is more used to being able to get everything compiling without something like elm-package.json and suggested we look at OCaml's Oasis for inspiration on how to support that usage in a nice way.

@evancz
Copy link
Contributor

evancz commented Sep 24, 2015

@laszlopandy, if you get a chance, I'd be curious if you think we can bring any ideas over.

@laszlopandy
Copy link
Member Author

That link makes it look like a cabal-type thing. Is there any info about
specifically what the good parts are?

On Thursday, September 24, 2015, Evan Czaplicki notifications@github.com
wrote:

@laszlopandy https://github.com/laszlopandy, if you get a chance, I'd
be curious if you think we can bring any ideas over.


Reply to this email directly or view it on GitHub
#23 (comment).

@jpierson
Copy link

@laszlopandy I noticed under For Library Authors there were no suggestions but I believe I have one from my own experience today. It looks like if no modules are specified for exposed-modules that elm-make will not build anything and just reports "Success! Compiled 0 modules.". I would suggest that a simple hint should be displayed at this point that says something along the lines of "If you want to make a library you need to list one or more modules as exposed-modules in elm-package.json".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants