emmabastas / elm-embed Goto Github PK

-- elm-generate-scripts/Foo.elm
module Foo exposing (exposed)
import Generate

exposed = Generate.Done ()
unexposed = Generate.Done ()

Here unexposed is evaluated, and included in the generated file, which it should not

Currently you can combine Embed.Task's with Embed.andThen, i.e one embedder can depend on the result of another one. You could for example use the value of an environment variable as the location for a configuration file read by an embedder, which then further affects the behavior of said embedder as it reads more files from disk. Now you have something that looks like a homecocked build system, which lies far outside the scope of elm-embed.

Are there situations where you genuinely need the power to combine embedders? The most legitimate example I can think of would be to have an environment variable to configure the location of a file to be read on disk. A workaround for that could be to use a symlink instead.

to reproduce:

1. elm make
2. elm-generate

error:

-- CORRUPT CACHE ---------------------------------------------------------------

It looks like some of the information cached in elm-stuff/ has been corrupted.

this is probably because elm-generate and elm share the same cache directory, they should have separate ones!

SSCCE

$ touch elm-embed-scripts
$ elm-embed init

To reproduce:

1. rm -r elm-stuff
2. elm-generate make
3. elm-generate make

error message NO GENERATORS

Currently Embed.File.read just passes the string to nodejs io functions. The behavior should be decoupled from nodejs, and be made more obvious.

How to go about compiling and testing for osx and windows is something I'll need to figure out. I don't have reliable access to either OS so might be a bit tricky.

SSCCE

$ echo y | elm init
$ echo y | elm-embed init

Put his in elm-embed-scripts/SSCCE.elm

module SSCCE exposing (foo)

import Embed

foo : Embed.Task Int
foo = Embed.succeed 1

$ elm-embed run

Remove type annotation from SSCCE.foo

$ elm-embed run now crashes

Removing elm-stuff/elm-embed resolves the issue

elm-embed run should ignore dotfiles.
There is no reason not to do this as far as I'm aware.

For me to make good design decisions it is critical to know what people would like to use elm-embed for.
So if you have a use case in mind, please leave a comment!

To reproduce:

1. elm make
2. elm-generate

You get a bunch of messages like

+-------------------------------------------------------------------------------
|  Corrupt File: /home/emma/.elm/0.19.1/packages/avh4/elm-color/1.0.0/artifacts.dat
|   Byte Offset: 26385
|       Message: not enough bytes
|
| Please report this to https://github.com/elm/compiler/issues
| Trying to continue anyway.
+-------------------------------------------------------------------------------