elm-lang / elm-make Goto Github PK

View Code? Open in Web Editor NEW

175.0 21.0 45.0 218 KB

A build tool for Elm projects

License: BSD 3-Clause "New" or "Revised" License

Haskell 100.00%

elm-make's Introduction

Merged into `elm/compiler`

elm-make's People

Contributors

Stargazers

Watchers

elm-make's Issues

Warnings from dependency packages on first time compile.

When you compile with either --warn or --report=json, just after you've run elm-package install, you get all the warnings from all the packages under elm-stuff the first run as they are being compiled. Most of these warnings are for "Native.SomeModule is unused". And since none of those files will get compiled again, the user never sees the warnings a second time. This can be very confusing the first time you compile in elm-vim with warnings enabled, for instance. Should unused native module warnings be suppressed?

This also relates to #27 in that warnings are important, but you'll miss them for any modules that don't need to be recompiled. So perhaps warnings should always be an opt in that forces everything to be recompiled so all your files are linted.

Print errors to stderr instead of stdout

In elm-test we generate a temporary .js file for the compiled Test.elm before running the tests.

By default that means we get output like this every time the tests run:

Successfully generated /var/folders/f2/bgdp00xs327b2qx7mmg6jkbh0000gn/T/elm_test_1151022-3235-1bxa84u.js
Successfully compiled Test.elm

This is pretty ugly, so what we've been doing is piping elm-make's stdout and discarding lines that start with "Success". This works, but introduces a new problem: because we're piping the output instead of just giving elm-make direct access to the console, we miss out on colorized error messages. (Thanks @evancz for pointing out the culprit!)

If elm-make wrote error messages to stderr and success messages to stdout, we could continue to pipe the stdout stream for filtering, but let stderr pass through as normal (colors and all), meaning everything would be rad and awesome!

Add support for filename and line number in json docs

This is used in, for example, the golang docs to link to the original source files. This could also be used by other tooling for 'jump to definition'.

My suggestion is the source entry in the example docs json below, or something like it:

"values": [{
  "name": "fromElement",
  "comment": "Embed an `Element` as `Html`.",
  "type": "Graphics.Element.Element -> VirtualDom.Node",
  "source": "src/Html.elm#110",
}]

Add location to errors when parsing headers

Just moving elm/compiler#853 to the relevant repo. Reproduce the error message with this to see that the file name is not reported:

module Foo (bar baz) where
bar = "bar"
baz = "baz"

Separate elm runtime library from app module

Currently if you make build of your elm app it goes in one bundle that contains elm runtime and also user module. But for production usage it would be better to keep them separate so runtime library can be cached by browser and if you make changes in your app users only have to download this app module. @rtfeldman what do you think?

Elm module names are case-insensitive on Windows/OS X, case sensitive on Linux

Example:

File b.elm

module B where
f = identity

File a.elm

import B

On Windows and OS X), there will be no error and it will work even though the file is called b.elm, not B.elm. On case-sensitive operating systems (Linux) it will create an error.

Expected behaviour should be that an error is raised on Windows too, or at least a warning.

In README, tell potential contributors how to build from source

That could be done by mirroring some of what is said in the READMEs of https://github.com/elm-lang/elm-lang.org, https://github.com/elm-lang/elm-compiler, or in a similar way to elm-lang/elm-package#160.

JSON reporting loop does not take the 'warn' argument into account.

Warnings should be opt-in like for normal reporting.

edit: This issue is that I am getting back warnings in the json reporter whether I asked for them or not. I will talk more about json reporting in issue #25, but it just seemed counter intuitive that changing the report format would change the behavior. I just thought it had been overlooked.

Warnings are only reported when the module is compiled

This isn't actually a bug, but a feature. The problem is that a module that has only warnings will compile correctly and so never show warnings after the first elm-make. The Main module seems to always be recompiled, but others don't.

If it weren't "elm-make --warn" but "elm-make --lint" it would make sense perhaps to force all code outside of elm-stuff to recompile so that warnings are always reported.

No kind checking?

The following compiles:

type alias Oops = List List
oops : List List
oops = []

The following gives a funny error:

oops : List List
oops = [[]]

Error:

The type annotation for `oops` does not match its definition.
3| oops : List List

As I infer the type of values flowing through your program, I see a conflict
between these two types:

    List

    List a

Invalid cabal dependency

Hello,

I was trying to build your project and I ran into a problem. I believe your cabal dependencies are invalid. Specifically,

elm-compiler >= 0.15.1 && < 0.16,

given that the available versions on hackage are,

0.14, 0.14.1, 0.15

http://hackage.haskell.org/package/elm-compiler.

Thanks,

Max

Warnings for infix toplevel annotations omit parentheses

Got this recently:

The correct annotation would include parentheses like so:

(=>) : a -> b -> (a, b)

For consistency, might also want parentheses in the warning message itself, e.g. "Top level value (=>) does not..."

add flag to print out types

Hi,

I very much liked 'elm -p' to check the result of the type inference. This feature is no longer present in 0.14. It would be great if it could be reimplemented.

Regards,

Volker

`elm-make` growing to consume infinite resources

I somehow managed to write an Elm file today that when run through elm-make caused elm-make to consume rapidly-increasing and seemingly unending system resources (see screenshot).

TL;DR: See the code at the end of the page.

I double-checked that the issue wasn't with the types by removing all code except the type declarations and successfully passing the file through elm-make. I would understand things blowing up if I punched an infinite list into elm-repl or had a recursive type alias that the compiler didn't catch. However, since elm-make just compiles and therefore doesn't run the code (I think?), and since it didn't choke on the data types when they were the only thing in the file, it seems like it was having issues compiling the functions defined in the file.

Although there are definitely errors in the code, it seems a bit unfriendly for new Elm users to have the compiler blow their entire system up if they make a mistake (elm-make pushed everything into swap so fast that the GUI locked up within the first few seconds). Is this a bug, or is there just some "gotcha" here that I/people need to be aware of?

Here's the original code and the corrected version, respectively:

-- This is the original attempt that caused `elm-make` to go crazy.
import Graphics.Element exposing (show)

import Dict exposing (Dict)

type alias Violation = String
type FormComponent comparable =
     FormComponent { error          : Dict comparable (List FormComponent)
                   , valdrViolations : Maybe (List Violation)
                   }

violations' comp =
  case comp.valdrViolations of
    Just xs -> xs
    Nothing -> Dict.values comp.error |> List.foldl (++) [] |> violations

violations comps =
  case comps of
    [] -> []
    (comp::t) -> violations' comp :: violations t

main = show "foo"

-- This is the modified version that works, with or without the type annotations.
import Graphics.Element exposing (show)

import Dict exposing (Dict)

type alias Violation = String
type FormComponent comparable = FormComponent
  { error           : Dict comparable (List (FormComponent comparable))
  , valdrViolations : Maybe (List Violation)
  }

violations' : FormComponent comparable -> List Violation
violations' (FormComponent comp) =
  case comp.valdrViolations of
    Just xs -> xs
    Nothing -> Dict.values comp.error |> List.foldl (++) [] |> violations

violations : List (FormComponent comparable) -> List Violation
violations comps =
  case comps of
    [] -> []
    (comp::t) -> violations' comp ++ violations t

main = show "foo"

Sidenote: This actually came about from having to solve a problem in my JavaScript day-job - I decided to solve it in Elm and then port the solution back over to JavaScript (because FP/Elm FTW). Because of this the data structures may not make the most sense for an Elm environment, but it's what the JS library we're using provides.

Friendlier elm-make interface for beginners

For end users (not creating a library)

For library creators

TODO

Default encoding is not always UTF-8

Thought this was fixed by #20 but appears to still be broken on some of our build servers 😿 (but not every build server, which is fun).

Symptoms

Running elm-make on some Linux machines results in the following:

elm-make: ././app/assets/javascripts/Quiz/QuestionStore.elm: hGetContents: invalid argument (invalid byte sequence)
elm-make: thread blocked indefinitely in an MVar operation

This has also been seen previously in elm/compiler#914

Workaround

The workaround is to run elm-make with the LANG environment variable set, like so:

LANG=en_US.UTF-8 elm-make Foo.elm

Error in package parsing/installation ignores --report=json flag

Hey, I made the Elm Linter package for Sublime Text 3, https://github.com/bbugh/SublimeLinter-contrib-elm-make 🍰

Problem: One of the issues I ran into is that packaging errors aren't reported by the json reporter. Instead, they are reported with the usual plaintext message. There's two specifically that I found and had to manually handle, but there is likely more. This means that I unfortunately had to handle each one individually as an edge case, so it's likely I've missed more. It's also not possible to highlight the line where the problem is, as these reports don't list a a line or column range.

Reproduction: The command used is elm-make --warn --report=json <filename>. Either of these lines will reproduce an error that is not json format:

The "Could not find module" error 🐴

import Horse

and the "Some packages are needed" error

-- without Http package installed
import Http

Desire: It would be much easier to use the json reporter if it was consistently reporting errors of all types!

I'd fork and submit a pull request to fix it, but I don't understand Haskell at all. I feel a bit silly that I can't even figure out where the error message text is coming from...

feature request: elm make clean

Occasionally, I've managed to get elm into a bad state. Not entirely sure how to reproduce but it goes something like this:

Install something with elm package
Use that thing for a while
Remove that dependency
Cached built JS gets out of step
Die at runtime

When this happens, its no big deal, and can be fixed by going into the elm-stuff folder and deleting my own user folder. When running make next time, as is well! However I don't like touching elm-stuff, so I'd like to request a way to clean out cached JS files. Perhaps a command like:

elm make clean

Error when generating the html output: commitAndReleaseBuffer: invalid argument (invalid character)

I am trying to compile a simple program and I am getting an error when generating the html output.
Here is a simple session, where I start with a folder that contains only the source file.

C:\Users\grzes\tmp>dir
 Volume in drive C is Windows8_OS
 Volume Serial Number is 22AA-55EE

 Directory of C:\Users\grzes\tmp

2015-08-14  02:34    <DIR>          .
2015-08-14  02:34    <DIR>          ..
2015-08-14  02:32                76 Hello.elm
               1 File(s)             76 bytes
               2 Dir(s)   9 035 051 008 bytes free

C:\Users\grzes\tmp>more Hello.elm
module Hello where
import Markdown
main = Markdown.toElement """Hello"""

C:\Users\grzes\tmp>elm package install evancz/elm-markdown --yes
Downloading elm-lang/core
Downloading evancz/elm-html
Downloading evancz/elm-markdown
Downloading evancz/virtual-dom
Packages configured successfully!

C:\Users\grzes\tmp>elm make Hello.elm --output Hello.html
Success! Compiled 38 modules.
elm-make.exe: Hello.html: commitAndReleaseBuffer: invalid argument (invalid character)

C:\Users\grzes\tmp>

I am using elm 0.15.1 on Windows.

C:\Users\grzes\tmp>elm
Elm Platform 0.15.1 - a way to run all Elm tools
...

I have installed from source.

The HTML is generated but the browser shows a blank page with no content.

C:\Users\grzes\tmp>dir
 Volume in drive C is Windows8_OS
 Volume Serial Number is 22AA-55EE

 Directory of C:\Users\grzes\tmp

2015-08-14  02:35    <DIR>          .
2015-08-14  02:35    <DIR>          ..
2015-08-14  02:34               426 elm-package.json
2015-08-14  02:35    <DIR>          elm-stuff
2015-08-14  02:32                76 Hello.elm
2015-08-14  02:35           193 455 Hello.html
               3 File(s)        193 957 bytes
               3 Dir(s)   9 030 238 208 bytes free

C:\Users\grzes\tmp>

The error is not shown when generating JS.

C:\Users\grzes\tmp>elm make Hello.elm --output Hello.js
Success! Compiled 0 modules.
Successfully generated Hello.js

Possible to generate warning and error reports at the same time (Problem for json)

Below is a reproducible program that generates a warning about Window being unused, and then error messages. With normal reporting it does not matter, but with json this produces the text for two different arrays of objects (one for warnings and another for errors.) This makes it sloppier in an IDE plugin to parse the report correctly.

It would be nice if all errors and warnings were in one single json array in the report.

module Main where

import Html exposing (..)
import Window

main = text + "Test"

elm-make 0.16 creates index.html by default

Using a command elm-make Module.elm used to create only elm.js -file, now it creates an index.html file. If this is intentional it might be worth a mention in the upgrade guide because it causes tools like emacs' compile buffer have new side-effects, like overwriting the index.html.

Lift restriction on multiple main modules now that the compiler supports it

Given that the compiler can now generate javascript with multiple main modules it may be possible to lift the restriction over here.

I noticed that the code checks whether modules are "public modules" before allowing them to pass the check, so I thought maybe these were "exposed-modules" in the elm-package.json.

At the moment we still need to compile this way:

elm_modules=`printf "\
      \nsrc/A/Main.elm
      \nsrc/B/Main.elm\
      \nsrc/C/Main.elm\
      \nsrc/D/Main.elm\
      \nsrc/E/Main.elm"`
elm-make $elm_modules --output elm-components.js --yes

Alternatively, perhaps the elm-package.json needs "main-modules" or something similar?

Ask Before Creating an elm-package.json file

The current behavior is bad because it doesn't tell the user it's going to create a file and the user may have input the command in error.

The interaction should be

1. Inform the user they don't have an elm-package.json and they need one to use elm-make
2. Ask if they want to make one
3. If yes, either interactively build one or tell them you put a default one in
4. Exit the program

the user can then fill it in and then install things the second time.

Simple error reports aren't sent as json with the "report=json" flag

The program below is one of a handful of errors that get passed straight through even when providing "--report=json" to elm-make.

module Main where

import Html Fexposing (..)

main : Html
main = text "Test"

Could not find uneeded type constructor error while checking types.

With the current head of my project (and using latest elm-make from git) I get this error when compiling for the second time:

Error in src/background/Main.elm:

Could not find type constructor 'GuiState.Action' while checking types.

make: *** [build/background/elm-background.js] Error 1

GuiState.Action is not a constructor that is needed for this compilation step. It is part of a previous compilation step (the application is separated into gui and background). You should be able to reproduce with these steps:

git clone [email protected]:kasbah/mooltipass.hid-app
cd mooltipass.hid-app
git checkout 7538052
make
touch src/background/Main.elm
make

The absence of the "--warn" flag is ignored in JSON reports

E.g., in the following you can see me not specifying "--warn" and yet getting the warning messages in the output:

Nikitas-MacBook-Pro:dca-elm mojojojo$ elm-make src/Main.elm --report=json
[{"tag":"unused import","overview":"Module `DCA.Rendering` is unused.","details":"","region":{"start":{"line":3,"column":1},"end":{"line":3,"column":34}},"type":"warning","file":"src/Main.elm"},{"tag":"unused import","overview":"Module `Svg` is unused.","details":"","region":{"start":{"line":6,"column":1},"end":{"line":6,"column":11}},"type":"warning","file":"src/Main.elm"},{"tag":"unused import","overview":"Module `Svg.Attributes` is unused.","details":"","region":{"start":{"line":7,"column":1},"end":{"line":7,"column":22}},"type":"warning","file":"src/Main.elm"},{"tag":"unused import","overview":"Module `Color` is unused.","details":"","region":{"start":{"line":8,"column":1},"end":{"line":8,"column":30}},"type":"warning","file":"src/Main.elm"},{"tag":"unused import","overview":"Module `DCA.Components.RecommendationsChart` is unused.","details":"","region":{"start":{"line":10,"column":1},"end":{"line":10,"column":67}},"type":"warning","file":"src/Main.elm"}]
Successfully generated elm.js

What's even more unfortunate is that there's no way to work around that.

Warnings and errors are collected into two separate json objects when using --report=json flag

Hey, I made the Elm Linter package for Sublime Text 3, https://github.com/bbugh/SublimeLinter-contrib-elm-make 🍰

Problem: When using a file that generates both a warning and an error, the json reporter outputs two separate json objects, which makes parsing challenging. Since the issues are already tagged as "warning" or "error" and have identical fields, it seems like a bug to output two separate objects.

Reproduction: Most of the time if there is an error and a warning, the compiler will simply ignore the warnings and output the errors. However, sometimes when the compiler decides to have both an error and the warning in the output, it will output two separate json objects. Unfortunately this only shows up intermittently and I am unable to reproduce a simple test case to demonstrate it. Here is an example that shows somewhat what the context would look like:

-- an unused module warning
import Http.Events

-- a cannot find type error
main : Potato
main =
  text "potato"

Although that is a contrived example, this is a real sample output:

[{"tag":"unused import","overview":"Module `Html.Events` is unused.","details":"","region":{"start":{"line":6,"column":1},"end":{"line":6,"column":19}},"type":"warning","file":"LintTest.elm"}]
[{"tag":"TYPE MISMATCH","overview":"The 1st argument to function `start` has an unexpected type.","subregion":{"start":{"line":48,"column":18},"end":{"line":48,"column":72}},"details":"As I infer the type of values flowing through your program, I see a conflict\nbetween these two types:\n\n    Model\n\n    Action","region":{"start":{"line":48,"column":3},"end":{"line":48,"column":72}},"type":"error","file":"LintTest.elm"}]

Desire: The json report would output as one single json object, which would make parsing much easier.

elm make autocomplete

When using elm make without the hyphen, tab does not complete filenames but it does when using elm-make. Is there a difference between the two commands that would explain this behaviour? Anyway, it's not really problematic but it is easier to type than-.

Unable to upgrade packages behind proxy

On versions 0.15, 0.15.1 and 1eaec5b (of elm-package), elm-make fails with the following output:

Elm-Platform/master/bin $ ./elm make
Some new packages are needed. Here is the upgrade plan.

Install:
elm-lang/core 2.1.0

Do you approve of this plan? (y/n) y
Downloading elm-lang/core
failed with 'ProxyConnectException "github.com" 443 (Left "StatusHeaders (Status {statusCode = 400, statusMessage = "Bad Request"}) HTTP/1.1 [("Date","Wed, 26 Aug 2015 07:12:07 GMT"),("Server","Apache/2.2.3 (Red Hat)"),("Content-Length","303"),("Connection","close"),("Content-Type","text/html; charset=iso-8859-1")]")' when sending request to
http://github.com/elm-lang/core/zipball/2.1.0/

The following environment variables are set:

$ echo $http_proxy
http://130.11.124.6:80
$ echo $https_proxy
http://130.11.124.6:80

I thought this was related to Issue 132 of http-client but it was fixed in version 0.4.16 and elm master is using version 0.4.20.

Coherent format for --report=json

Right now the JSON spit out is haphazard. Folks don't like that warnings and errors are separate. It'd be good to add information about successes, dependency structure, etc.

Issues that touch on this include: #42, #25

UX of "Error reading build artifact"

After upgrading to Elm 0.15.1, I get this:

Error reading build artifact elm-stuff/build-artifacts/elm-lang/core/2.1.0/Array.elmi
    The file was generated by a previous build and may be outdated or corrupt.
    Please remove the file and try again.

Is there any reason not to structure elm-stuff like this?

elm-stuff/
  build-artifacts/
    0.15.0/
      NoRedInk/
      elm-lang/
      evancz/
    0.15.1/
      NoRedInk/
      elm-lang/
      evancz/

This seems like it would make it so I never had to see this error again. 😄

This creates a JavaScript file, not an HTML file: elm-make Main.elm --output=main.htm

I installed the latest version of Elm via cabal. When I copy-paste this "hello world" program into a file Main.elm and then run

elm-make Main.elm --output=main.htm

as instructed in the README except with a .htm extension, I get a file at main.htm which looks like:

var Elm = Elm || { Native: {} };
Elm.Basics = Elm.Basics || {};
Elm.Basics.make = function (_elm) {
   "use strict";
   _elm.Basics = _elm.Basics || {};
   if (_elm.Basics.values)
   return _elm.Basics.values;
   var _op = {},
   _N = Elm.Native,
   _U = _N.Utils.make(_elm),
...
                      ,line: line
                      ,leftAligned: leftAligned
                      ,rightAligned: rightAligned
                      ,centered: centered
                      ,justified: justified
                      ,plainText: plainText
                      ,markdown: markdown
                      ,asText: asText};
   return _elm.Text.values;
};

This is JavaScript, not HTML.

It appears that the tool has different behavior depending on the file extension of the filepath passed in the output argument. IMO, this behavior difference should be toggled by a separate flag, e.g. --outputtype=html.

--report=json doesn't return JSON

So far I've encountered 4 scenarios:

Compile fails. JSON returned.
Compile succeeds. JSON appended with string like Successfully generated build/index.html.
Regardless above I occasionally get JSON prepended like Packages configured successfully!
#26

For now I'm splitting output on new lines and parsing them separately. But it's been error prone. Maybe make needs a JSON wrapper with keys like result and status.

elm-make as Library

It would be great if elm-make had a Haskell library interface. This would make it much easier to implement things on top of it, e.g., the IO/testing stuff.

All I really need is to be able to run the equivalent of elm-make <File.elm> --output=<File2.js> with a library function instead of relying on the user's PATH being correct.

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

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.

Implementing short description for elm-make when no arguments provided.

I had my first experience with elm-make today. After a bit of asking around and peeking into documentation, I did manage to use to build an Elm file.

I also did try -h to find the usage of elm-make. However, I sorta guessed that it would be a valid option. It would be great if a short usage info could be provided when no arguments were supplied. This would really help with a first time experience.

Something like

elm-make 0.1, (c) Evan Czaplicki 2014

-h, --help for help

Add a `--style="path/to/style.css"` option for when compiling to `.html`?

Which would just add into the generated html head?

Something along these lines might be useful as there currently doesn't seem to be a way to programmatically link a stylesheet (please correct me if I'm wrong!).

Access is denied?

elm-make: elm-lang-core-5204441: MoveFileEx "elm-lang-core-5204441" "2.1.0": permission denied (Access is denied.)

I get this various either running the elm-reactor or when using elm-package.

New to elm so not sure how to proceed.

Of note, when using elm-reactor I often find either restarting command console or refreshing browser multiple times, or both, seems to sort this.

Is this an expected behaviour under elm-reactor?

I have not been able to plod through task-tutorial from command console using elm-package as it never gets past the error.

I am running Windoze 10 and have tried both user and admin versions of command console.

any hints?

Cheers,
B

Copypasta: s/package/make

On this line:

https://github.com/elm-lang/elm-make/blob/master/src/Arguments.hs#L70

This should read "elm-make" not "elm-package".

Cache invalidation bug when building multiple files

Running elm-make on two files in the same project fails to properly build the second file. E.g. if you run

elm-make --yes --output=build/a.html src/a.elm
elm-make --yes --output=build/b.html src/b.elm

then build/b.html ends up being identical to build/a.html.

I've created a repo at https://github.com/jwmerrill/elm-compiler-stale-cache to demonstrate this problem.

Support structured errors

With 0.15.1 the compiler got structured errors that are easy to spit out as JSON. This has not been added to elm-make yet, errors found in elm-make just cause things to stop running with some string printed out.

Issues that are asking for this in various ways include: #41, #26, #38

Disallow `exposing (..)` in exposed modules for semver guarantees

It is currently possible for a published package to break a build without undergoing a major version number bump, if it uses exposing (..) and one of its dependencies adds something that causes a namespace conflict.

A given package can prevent itself from causing namespace conflicts like this by never using "exposing (..)" in its imports. I tried doing that for a library in a case where I would normally use "exposing (..)" for the elm-html DSLs, and it was surprisingly little extra effort: https://github.com/NoRedInk/elm-html-widgets/blob/master/src/Accordion.elm

Elm could turn this practice into a guarantee by enforcing a rule like "if you have exposed modules, you must document all your exposed functions and you cannot use exposing (..) in your imports."

This was originally discussed on elm-dev, and discussion should continue there.

elm-make or compiler gets state corrupted, needs manual reset

Here is what happened:

worked on a small project (3 modules) for a few hours
introduced an type-error across 2 modules and noticed it was not caught by elm-make
manually deleted the elm-stuff directory and re-ran elm package install
ran elm-make again and it caught the type error

So it seems some state got corrupted in elm-stuff. I cannot provide a repeatable test.

Versions: elm-make 0.2 (Elm Platform 0.15.1)

Add CommonJS/Node/AMD snippet to end of compiled output

See elm/compiler#1029 for discussion that led to this.

The following should be incorporated into the output JS of compiled Elm files.

(function() {
  var Elm = ... // current emitted code goes here

  if (typeof define === "function" && define.amd) {
    define([], function() {
      return Elm;
    });
  } else if (typeof module === "object") {
    module.exports = Elm;
  } else {
    if (typeof this.Elm === "undefined") {
      this.Elm = Elm;
    } else {
      throw new Error("This page is trying to import multiple compiled Elm programs using the same `Elm` global object, which would cause conflicts. This can be resolved by using a module loader like RequireJS to import the compiled Elm programs into different objects.")
    }
  }
}).call(this);

PREVIOUS VERSION:

This version is more "stock" and will silently overwrite any previous Elm globals defined on the page...which seems far less desirable than crashing early with a helpful message.

(function() {
  var Elm = ... // current emitted code goes here

  if (typeof define === "function" && define.amd) {
    define([], function() {
      return Elm;
    });
  } else if (typeof module === "object") {
    module.exports = Elm;
  } else {
    this.Elm = Elm;
  }
}).call(this);

elm-make does not work offline

If I disconnect from the Internet and run elm-make Foo.elm, I get:

failed with 'FailedConnectionException2 "package.elm-lang.org" 80 False getAddrInfo: does not exist (nodename nor servname provided, or not known)' when sending request to
    <http://package.elm-lang.org/all-packages?elm-package-version=0.5.1&since=2015-07-13%2017%3A23%3A43.521832%20UTC>

This was an unwelcome surprise to find when trying to code on a four-hour flight with no WiFi. 😿

Generate docs for subpackages

So that tools can use the docs for dependency packages without need to run elm-make --docs under each one.

Emit compiled JS to stdout

(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!

Is it possible to specify output directory and default build command ?

I'm currently running a build with a command like this:

elm-make elm/thm.elm --output public/javascripts/thm.js

My elm-package.json specifies a "source-directories" folder ; is there an option to make it push compiled js files directly to "public/javascripts", by default ?

Also, is there an option to make a build "default" ? When running elm-make without arguments, it returns a message Success! Compiled 0 modules. ; what is such a command supposed to do ?

(I'm sorry if this is all in the docs somewhere, I could not find a reference for the elm-package.json file.)

Rationale for when to show "========== ERRORS ========="?

When I try to compile the program

import Graphics.Element

main = Graphics.Element.show

I get:

Detected errors in 1 module.
==================================== ERRORS ====================================

-- BAD MAIN TYPE ------------------------------------------------------ Test.elm

The 'main' value has an unsupported type.

3│ main = Graphics.Element.show
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I need an Element, Html, (Signal Element), or (Signal Html) so I can render it
on screen, but you gave me:

    a -> Graphics.Element.Element

When I try to compile the program

import Graphics.Element

main = Graphics.Element.show (1+"s")

I get:

Detected errors in 1 module.
-- TYPE MISMATCH ------------------------------------------------------ Test.elm

The right argument of (+) is causing a type mismatch.

3│                               1+"s")
                                   ^^^
(+) is expecting the right argument to be a:

    number

But the right argument is:

    String

Hint: To append strings in Elm, you need to use the (++) operator, not (+).
<http://package.elm-lang.org/packages/elm-lang/core/latest/Basics#++>

Hint: I always figure out the type of the left argument first and if it is
acceptable on its own, I assume it is "correct" in subsequent checks. So the
problem may actually be in how the left and right arguments interact.

Why is there the line(s)

==================================== ERRORS ====================================

in one case but not in the other?

Revising elm-package.json for more scenarios

This is based on @laszlopandy's issue #49 where he proposed adding two fields: "main-modules": [ "Main" ] and "build-output": "build/my-elm.js". After the discussion there, here is the revised version.

The elm-package.json file would be renamed to elm-project.json with the goal of covering the two major kinds of projects: packages that want broad dependencies and products that want exact dependencies.

If elm-project.json has a exposed-modules field, it must be a package. If it has a main-modules field, it must be a product. These would be mutually exclusive and the product version would be the default.

For Products

For products, the elm-project.json file would be something like this:

{
    "source-directories": [
        "src"
    ],
    "main-modules": [
        "Main"
    ],
    "output": "build/my-elm.js",
    "dependencies": {
        "elm-lang/core": "2.1.0"
    },
    "elm-version": "0.15.1"
}

Notice that the dependencies are all exact versions here. This means you can never have anything freaky happen due to some weird change in a dependency. (Oh, unless there is some weird change in a transitive dependency and the solving algorithm is nondeterministic or changes for some reason.)

My main questions questions are:

Should the elm-version field be exact too? What if someone tries to use 0.15.2? Should it fail? This whole flow seems weird.
What is the experience do people have when installing a new package? Maybe you can add the package, but the precise versions listed need to be slightly updated. The dependency solving algorithm would need to map 2.4.2 to 2.0.0 <= v < 3.0.0 or something like or it will miss a lot of solutions and the user will have to work all this out in their head.

I don't want to discuss question 2 here. This points at having a more flexible solver and that's a discussion of its own.

For Packages

The elm-project.json file would look something like this:

{
    "version": "1.0.0",
    "summary": "helpful summary of your package, less than 80 characters",
    "repository": "https://github.com/USER/PROJECT.git",
    "license": "BSD3",
    "source-directories": [
        "src"
    ],
    "exposed-modules": [
    ],
    "dependencies": {
        "elm-lang/core": "2.0.0 <= v < 3.0.0"
    },
    "elm-version": "0.15.0 <= v < 0.16.0"
}

This would work just like the current elm-package.json so I don't have any big concerns here.

Issue Updates

Guess github user name? elm-lang/elm-package#131