rtfeldman / node-elm-compiler

A Node.js interface to the Elm compiler binaries.

node-elm-compiler

Wraps Elm and exposes a Node API to compile Elm 0.19 sources.

Example

$ npm install
$ cd examples
$ node compileHelloWorld.js

Releases

5.0.5

Upgrade find-elm-dependencies and lodash dependencies to fix CVE-2020-8203 vulnerability.

5.0.2

Upgrade lodash dependency to fix security audit warning. (#93)

5.0.1

Add helpful errors if you use the obsolete warn and pathToMake flags. (#75)

5.0.0

Add 0.19 support. Remove yes option. Add optimize option. Throw exceptions instead of emitting warnings or using process.exit.

4.5.0

Add runtimeOptions

4.4.0

Add compileToStringSync

4.3.1

Upgrade findAllDependencies dependency to correctly report all dependencies within a multi-source-directory project.

4.3.0

Add compileSync via @yormi

4.2.1

Epic perf improvements from @eeue56

4.2.0

Add support for --debug flag.

4.1.5

Clean up temporary directories more safely.

4.1.4

findAllDependencies now supports port module files.

4.1.3

Use utf-8 encoding for compileToString

4.1.2

Support checking dependencies for modules with no module declaration.

4.1.1

Fix bug in dependency searches beginning with a non-root Main module.

4.1.0

Log elm-make output in verbose mode.

4.0.1

Fix missing temp dependency.

4.0.0

Use an Error object for result errors instead of a string.

3.0.0

Passing the warn option now passes --warn to elm-make, and emitWarning now controls warning logging.

2.3.3

Fix bug where nonzero exit codes were not rejecting promises.

2.3.2

Fix bug related to converting module dots to directories in nested dependency resolution.

2.3.1

Move temp dependency out of devDependencies

2.3.0

Added #compileToString

2.2.0

Added cwd to options and fixed a bug where Windows couldn't find elm-make.

2.1.0

Added #findAllDependencies

2.0.0

No longer searches node_modules/.bin for elm-make - now if you don't specify a pathToMake option, only the one on PATH will be used as a fallback.

1.0.0

Initial release.

node-elm-compiler's Issues

parcel : node-elm-compiler : ENOENT when elm installed localy (vs globably)

Hi,

I always install my tooling like local dependencies instead of making all global, an other debate.
To make it work I use to have in the PATH ./node_modules/.bin and running all commands from the root project directory

Seems node-elm-compiler spawn process by setting cwd to the sub directory where sources are stored, spawn doesn't find the elm binary.

warn: true blew up

I passed warn:true to this and got a runtime TypeError saying logWarning was not defined.

Removing warn: true fixed the problem. Not sure what the ultimate culprit is, but issuing this so I don't forget.

Here's where I fixed it; the parent commit reproduces the error: rtfeldman/elm-css@986fa8b

Version 5.0.2 missing index.js

It looks like v5.0.2 was published to npm without compiling the typescript. After npm install node-elm-compiler:

▶ tree node_modules/node-elm-compiler                                                   
node_modules/node-elm-compiler
├── appveyor.yml
├── examples
│   ├── compileHelloWorld.js
│   ├── elm.json
│   └── HelloWorld.elm
├── LICENSE
├── package.json
└── README.md

1 directory, 7 files

lodash's vulnerabilities strike again

There's a couple new vulnerabilities being reported by npm audit in regards to lodash:

Tests failing

I notice the unit tests are failing on master. Do you need any help getting these green again?

Remove stale branches

Most branches on this repo are already merged. Only read-deps is not, but that is behind master by more than 200 commits.

I would suggest removing all these branches to keep the repo tidy.

Passing a non-existing pathToElm does not properly throw

I'm trying to upgrade run-elm to 0.19 and am leveraging [email protected] where #68 is finally fixed 🎉

One case I struggle to make working is when pathToElm (former pathToMake) points to a non-existing file or a directory. When I'm calling compileToString, I expect this function to reject a returned promise, however it does not and I see the following error in stderr:

spawn /path/to/non-existing/elm ENOENT

When an argument is a directory, the message changes to this:

spawn /path/to/dir EACCES

In the second case I also see:

    TypeError: Cannot read property 'setEncoding' of undefined

      at node_modules/node-elm-compiler/index.js:136:23
      at node_modules/temp/lib/temp.js:252:7
      at node_modules/graceful-fs/graceful-fs.js:241:16

I know I can reconfigure or replace spawn via options, but I'm curious if out-of-box behaviour is worth changing in the first place.

---

You can reproduce the issue by cloning jfairbank/run-elm#17 and renaming test/integration/case-projects/path-to-elm/test-config.skip.js with test-config.js. Alternatively, you can just add these two tests in your suite: kachkaev@ead53cc.

TypeScript

Would there be interest in adding types via TypeScript? I think I could help work on it.

process.exit(1) makes it hard to use node-elm-compiler via require()

It'd be great a call to process.exit(1) was removed to make it possible to use the module via require()

node-elm-compiler/index.js

Lines 96 to 105 in 40c832b

	try {
	return runCompiler(sources, optionsWithDefaults, pathToMake)
	.on('error', function(err) {
	handleError(pathToMake, err);
	process.exit(1);
	});
	} catch (err) {
	handleCompilerError(err, pathToMake);
	}

There is another occurrence of this method, but the line is never reached:

node-elm-compiler/index.js

Lines 69 to 78 in 40c832b

	function handleCompilerError(err, pathToMake) {
	if ((typeof err === "object") && (typeof err.code === "string")) {
	handleError(pathToMake, err);
	} else {
	console.error("Exception thrown when attempting to run Elm compiler " + JSON.stringify(pathToMake) + ":\n" + err);
	}
	throw err;
	process.exit(1);
	}

findAllDependencies can be very slow

I stumbled across this using https://github.com/rtfeldman/elm-webpack-loader. I was getting extremely slow build times (60 seconds+) even though elm would compile the code in under a second. I traced it to https://github.com/rtfeldman/elm-webpack-loader/blob/master/index.js#L45 which was what was taking the majority of the 60 seconds. As a temporary fix for elm-webpack-loader I did a simple file system search for elm files which is good enough for our case https://github.com/zapnito/elm-webpack-loader/blob/master/index.js#L56.

I'm not sure what the best fix is here. One strategy might be to grab the src folders from elm-package.json and do a recursive search for all *.elm files. Perhaps the existing implementation solves a scenario this wouldn't satisfy though? (I suppose it will avoid the inclusion of any files that aren't imported anywhere). Another option would be to add a solution specifically to elm-webpack-loader and leave this one alone.

Support for upcoming --debug flag

Elm 0.18 will ship with a --debug flag embedding an actions debugger to the program. It would be nice if this would be exposed here so elm-webpack-loader can take advantage of it when 0.18 lands

Resolving dependencies for nested modules doesn't use appropriate root directory.

Here's an example:

/src
   /Components
      /MyComponent
         MyComponentMain.elm
         View.elm
         Update.elm
         Model.elm

MyComponentMain might be defined as

module Components.MyComponent.MyComponentMain where

import Components.MyComponent.View
import Components.MyComponent.Model
import Components.MyComponent.Update

...

Since the main module is located at src/Components/MyComponent/MyComponentMain.elm (ie elm-make src/Components/MyComponent/MyComponentMain.elm) then all resolved dependencies will be relative to that directory. For example:

src/Components/MyComponent/Components/MyComponent/View.elm
src/Components/MyComponent/Components/MyComponent/Model.elm
src/Components/MyComponent/Components/MyComponent/Update.elm

Some ideas

1. Search for modules starting at the source directories specified in the nearest elm-package.json
2. Set the base directory starting at (src/Components/MyComponent/) and moving up N directories where N is the number of . in the module name.

Errors on Windows with paths containing spaces

This line doesn't work on Windows with paths containing spaces as it passes the path directly as an argument to the command-line.
E.g. if info.path is C:/Program Files/[...] the command executed is elm make --output=C:/Program and the rest is truncated and the command errors with invalid path. Simply wrapping the path in "'s should work, e.g., options.output = '"' + info.path + '"', but I'm not sure if it's sufficient for other edge-cases.

node-elm-compiler/src/index.ts

Line 132 in d81a4c7

options.output = info.path;

`spawn ENOENT` on Windows

Trying to spawn elm-make on Windows results in a NOENT error, even if your PATH is correctly configured to look in the npm folder. I believe this is caused by this issue on Node: nodejs/node-v0.x-archive#2318

Using something like cross-spawn should solve the issue.

Add ENOENT handling for nonexistent CWD

Contrary to the error message surfaced by compilerErrorToString, ENOENT can also be thrown due an attempt to run from a non-existent directory. This is likely to occur if a user is using elm-webpack-loader as the cwd field there is easily to make an error when writing, and passed through directly to the spawn call.

Support multiple main files... take 2

Basically #26 with literally the same use case as this #26 (comment). It appears like this issue was forgotten for a while.

node-elm-compiler depending on vulnerable package (lodash)

A recent vulnerability was found in older versions of lodash (the version that elm-webpack-loader seems to depend on). Result of npm audit:

                       === npm audit security report ===                        
                                                                                
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.17.11                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ elm-webpack-loader [dev]                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ elm-webpack-loader > node-elm-compiler >                     │
│               │ find-elm-dependencies > lodash                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/782                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.17.11                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ elm-webpack-loader [dev]                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ elm-webpack-loader > node-elm-compiler > lodash              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/782                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 2 moderate severity vulnerabilities in 23118 scanned packages
  2 vulnerabilities require manual review. See the full report for details.

pathToMake and elm 0.19

Hi,

now that elm-make isn't a separate binary, should this option not just be pathToElm and append the "make" bit?

thanks

Dan

Support multiple main files

elm-make supports multiple main files by specifying each elm file to the make command.

Color output for errors?

Sometimes the type signatures in compiler errors are huge. In those cases it'd be super nice to have the color highlighting which elm make provides, instead of having to diff them by eye.

I did some investigation and it seems like when the compiler is run with processOpts:{stdio: "pipe" } then the colors are lost.

I actually managed to get colors working with this ugly hack:
node-elm-compiler/index.js : line 148

compiler.on("close", function(exitCode) {
    if (exitCode !== 0) {
      compile(sources, Object.assign({},options,{ processOpts:{stdio: 'inherit' }}));
      return reject('Compilation failed');
     //etc...

(if the compilation fails, then rerun the compiler with processOpts:{stdio: 'inherit' } which sends the output straight to the terminal)

Not sure how you would do it properly though. Maybe this is a limitation of the cross-spawn package?

Support passing --warn to Elm

It would be nice to see Elm’s warnings emitted via Webpack.

$ elm make --help
elm-make 0.16 (Elm Platform 0.16.0)

Usage: elm-make [FILES...] [--output FILE] [--yes] [--report FORMAT] [--warn]
                [--docs FILE]
  build Elm projects

Available options:
...
  --warn                   Report warnings to improve code quality.

Add a way to retrieve the warnings from Elm Compiler

As of today warnings are printed out with a console.log call

This is not ideal for situations, where users might want to do something with the warnings, e.g. pass them down to Webpack or apply some additional formatting.

I don't really have a good idea on how exactly the API for this could look, but it would improve elm-community/elm-webpack-loader

I'm pretty open to the idea of working on a PR for this, I just need some guidance in terms of API design(if the suggestion above makes sense) 🙂

Revert setting env variables

We should be able to revert #3 in light of elm-lang/elm-make#20, which fixes that problem directly in elm-make itself since 0.15.1.

Support `--docs` flag

In the application I'm currently working on we use the documentation generated by --docs (which we then serve from our backend) to create in-app documentation for our own code. Since we use webpack with https://github.com/elm-community/elm-webpack-loader/ it would be nice if we could pass this flag so the JSON file gets generated on each change.

Will there be any issues regarding for example re-reading the elm-package.json because we'll then need to know which modules are exposed? Or maybe that'll only be an issue for the webpack loader? I can imagine it might conflict somehow with incremental builds - which, in that case, should probably be handled by the webpack loader itself.

I am not familiar with the codebase for neither this lib nor the webpack loader so I get it if there are specific reason for the white listing of compiler arguments.

Flaky build

The AppVeyor tests failed a few times(first, second, third) as well as Travis (first, second) because of issues with the elm-stuff cache.

It is always the #compileToString works when run multiple times test that throws an errors stating elm-stuff is corrupt.

compileToStringSync?

Not sure if this is the right use case, but I'm trying to integrate Elm into my React application. My tests are all in Jest and it would be nice if I could keep them passing during the transition. I'm trying to get this working as a Jest transform, but they require synchronous compilation, and it looks like they have no intention of supporting an asynchronous transform. Is there any possibility of getting a synchronous version of compileToString?

findAllDependenciesHelp can get into an infinite loop

I have a case where I can get findAllDependenciesHelp into an infinite loop.
After placing this statement in findAllDependenciesHelp before returning the Promise:

console.log("node-elm-compiler: findAllDependenciesHelp - " + file);

I got this output:

node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Icon.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Options.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Options/Internal.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Options.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Options/Internal.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Options/Internal.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Tooltip.elm
node-elm-compiler: findAllDependenciesHelp - /Users/bparadie/git/research/elm/mc_client/src/Coral/Icon.elm
...

I looked at the code and I couldn't find any code that would check whether file was already in knownDependencies. The problem is actually fixed when you add this code to findAllDependenciesHelp:

if( knownDependencies.indexOf( file ) >= 0 )
{
  return;    
}

Now, the interesting thing is that this infinite loop is most likely responsible for a bunch of problems that appear to be webpack out-of-memory bugs like this one here. I suspect that findAllDependenciesHelp is happily looping and slowly draining V8's memory.

I have a hunch that this patch will also fix elm-community/elm-webpack-loader#62 .

Elm 0.18

The readme states that version 0.17 is supported - what would it take to support 0.18?

node-elm-compiler.findAllDependencies ignores imports after "{- -}"-comment

Dependencies are not correct evaluated if there is a one-line comment with "{- ... -}" between them.
As a result elm-webpack-loader does not watch all files, webpack does not build after change of missing dependent files.

Steps to reproduce:

Sample code Main.elm:
module Main exposing (..)

    import Html exposing(..)

    -- internal modules

    import Init exposing (..)
    import Msgs exposing (..)
    import View exposing (..)
    import Update exposing (..)
    import Subscriptions exposing (..)
    ...

gives following dependencies:
Dependencies: [ '/tmp/dep_fail/src/Init.elm',
'/tmp/dep_fail/src/Msgs.elm',
'/tmp/dep_fail/src/View.elm',
'/tmp/dep_fail/src/Update.elm',
'/tmp/dep_fail/src/Subscriptions.elm',
'/tmp/dep_fail/src/Models.elm' ]

Changing line "-- internal modules" to "{* internal modules *}":
module Main exposing (..)

    import Html exposing(..)

    {- internal modules -}

    import Init exposing (..)
    import Msgs exposing (..)
    import View exposing (..)
    import Update exposing (..)
    import Subscriptions exposing (..)
    ...

gives no dependencies:
Dependencies: []

Moving comment line "{* internal modules *}" after "import Init ...":
module Main exposing (..)

    -- external modules

    import Html exposing (..)
    import Init exposing (..)

    {- internal modules -}

    import Msgs exposing (..)
    import View exposing (..)
    import Update exposing (..)
    import Subscriptions exposing (..)
    ...

gives Init.elm and its dependencies:
Dependencies: [ '/tmp/dep_fail/src/Init.elm',
'/tmp/dep_fail/src/Models.elm',
'/tmp/dep_fail/src/Msgs.elm' ]

Following script used for getting the dependcies:
'use strict';
var elmCompiler = require('node-elm-compiler');
var file = "./Main.elm";
elmCompiler.findAllDependencies(file).then(function (dep) {
console.log("Dependencies: ", dep);
}).catch(function(v) {
console.log("Dependencies failed");
});

Add some Travis tests

Look to grunt-elm for a reasonable starting point.