Add fields to elm-package.json for argument-less elm-make

[laszlopandy]

I propose adding two fields to elm-package.json:

• "main-modules" : [ "Main" ], which would search for Main.elm inside all defines source-directories. Multiple main modules are also allowed.
• "build-output" : "build/my-app.js", which would be used as the default output path

With this, instead of writing:
elm make src/Main.elm --output build/my-app.js
I can simply write:
elm make
and it will know what to do. This is a big win because you can checkout any elm project and build it without reading any instructions.

[texastoland]

This is what I meant in #23. Sublime is already doing this 👍 I could migrate to use these fields.

[rtfeldman]

If only one Main is allowed in this proposal, then we can eliminate a class of errors by replacing e.g. Elm.fullscreen(Ekm.Main) (runtime error - Ekm is undefined) with just Elm.fullscreen().

@rehno-lindeque - you guys currently have a use case for multiple mains, right? Is there another way you could accomplish the same thing, such as multiple elm-package.json files?

[texastoland]

For that use case in Sublime we just assumed it's have to be passed into the CLI.

[rehno-lindeque]

@rtfeldman That's right - every widget we have has a main (in order to be embedded separately). At the same time the widgets have a lot of shared code, we wouldn't want to have multiple .js files output because that would get huge pretty quickly... (also, even more boilerplate for one elm-package.json per widget)

[texastoland]

What's your process currently?

[rehno-lindeque]

Mmm, well it's pretty simple really - I remember now that we're not even directly using elm-package.json for building. I should have checked!

elm_modules=`printf "\
      \nsrc/Bom/Substitutes/Main.elm\
      \nsrc/ConsignSource/Main.elm\
      \nsrc/Footprint/Main/Overlay.elm\
      \nsrc/Symbol/Main.elm\
      \nsrc/Dashboard/Main.elm\
      \nsrc/ProjectUpload/Main.elm\
      \nsrc/Board/Main.elm\
      \nsrc/UserPart/Main.elm\
      \nsrc/UserSource/Main.elm"`
elm-make $elm_modules --output client/elm-components/elm-components.js --yes || die

[jinjor]

I still don't understand well. Should we use one large .js file which includes multiple mains for all pages? I usually make multiple .js files for multiple pages (e.g. indexPage.js for index.html, profilePage.js for profile.html and so on).

[rehno-lindeque]

@jinjor at least for us, there's a huge amount of shared code that gets compiled into our javascript output. I'd say just open your indexPage.js, profilePage.js and look inside. If there's a lot of redundancy you might want to consider doing what we do.

[jinjor]

Ah, now I understand what you meant, thanks. I'm not sure it should become the standard way, but in many cases it seems better considering browser cache.

[evancz]

I want a way to add constraints appropriate for a package vs a product. (Products get exact constraints whereas packages get the widest verifiable constraints possible.)

@laszlopandy, what do you think of making the main-modules and exposed-modules fields mutually exclusive? This can serve as the indicator of whether we are dealing with a package or product.

[rtfeldman]

A big +1 to making them mutually exclusive! We still accidentally mess this up all the time.

Would be an added bonus if the main-modules version used a more concise version syntax (e.g. "1.0.0" instead of "1.0.0 <= v <= 1.0.0")

[evancz]

Interesting, that seems very nice @rtfeldman. @rehno-lindeque, do you have opinions on this?

(This would also be independent of a test-dependencies or dev-dependencies field for any constraints that are just for testing or benchmarking or whatever. Would you want exact or bounds in that case though? Is it the same answer for packages and products? Assuming this can be handled independently, I think we should discuss it in a separate issue.)

I am struggling to think of legitimate cases of something being both a package and a product. When we add support for "local packages" via elm-package this should handle the scenario within a company where you have a closed-source package that is used your closed-source product.

I have been playing with the idea of having something like elm-package.json and elm-product.json but that seems pretty confusing. I have also been thinking about having a field within elm-package.json like "type": "package". The idea here seems better than both, but does the name elm-package.json still make sense? I don't know if it makes sense to change this before 0.16, but let's start getting some ideas.

[evancz]

Maybe it should be named elm-project.json?

And then some projects are packages and some are products. That's determined by whether you use exposed-modules vs main-modules.

[rtfeldman]

Love the idea of elm-project.json - makes a ton more sense!

I'm not even sure what it would mean to import someone else's publicly-published package that had a main specified in the JSON file. Would that be meaningfully different from someone publishing a package that exposed some function that happened to be called main, and then I made a local project that used the published package as a dependency and then set the appropriate function they exposed to be my main?

Also as far as test-dependencies and dev-dependencies - I think fields like that add unnecessary complexity if you have "local packages." Given local packages, I can just make a new json file for my testing project which adds the application package as a dependency along with elm-test and the like (which is exactly what we do now at work, except with all the application dependencies manually copied in both places), and use the same strategy for my dev build project (assuming that use case materializes).

[evancz]

I'm not even sure what it would mean to import someone else's publicly-published package that had a main specified in the JSON file.

I wouldn't let that happen, so let's not go too deep into that. It was more a question of "are there times when a single project is legitimately both a package and a product?" But if that's ever the case, it seems like you could make 99% of things a package and the Main module a product.

I think the test-dependencies idea is getting too off track, let's drop that for now.

---

I did a bit more thinking on the idea of pinning to exact dependencies. This would mean running elm-package install on something new is more likely to fail than normal. I think it makes sense to have different solving strategies in both of these cases to have a nice experience. So my feeling is that I can't do this for 0.16 but the idea is interesting.

I'm going to open an issue summarizing the current state of affairs.