Typechecking can be circumvented by compiling individual modules

[mgold]

Moved from elm-lang/elm-compiler#1193. @colinmccabe wrote:

Say you have three modules, Main, A and B.

Main imports A and A imports B, so the dependency graph looks like this:

Main <- A <- B

1. Suppose the program typechecks initially. Build the entire module graph with elm-make Main.elm
2. Change the signature of a function in B that is called by A, but do not update A.
3. Run elm-make B.elm. This succeeds as expected since B is internally consistent.
4. Run elm-make Main.elm. This succeeds, even though A is inconsistent with B!

In step 4 elm-make doesn't appear to check if A and B are consistent with each other since they are already built.

However, the timestamp on B's compiled assets (from step 3) will be later than A's compiled assets (from step 1). One possibility is to detect when an imported module has changed more recently than its importer, and recompile it.

The easiest fix is to always recompile everything, but this removes all benefits of caching.

[mgold]

Come to think of it, this is essentially FRP all over again -- changes propagate down the dependency DAG.

[SandiCat]

I have this exact same issue. It makes developing inconsistently weird.

[mgold]

GNU Make solves this, right? I think using timestamps like I originally suggested. You'd just have to extract the dependency graph from the source. You'd have to traverse the graph entirely: Main's dependency A is older than it, which is good, but A's dependency B is younger than it, which is bad.

[smerchek]

I run into this a lot and was considering opening this very same issue. It is probably to some degree an artifact of my use of Atom with Elm integration. At first, I thought I found my first elm runtime error, but in fact the compiler didn't compile everything!

To fix in the meantime, I run rm -rf elm-stuff/build-artifacts/0.16.0/<user>/<repo> on build.

[sporto]

I'm having the same issue while using https://github.com/rtfeldman/elm-webpack-loader or using elm-make in Sublime I often get successful builds when in reality things are broken resulting in runtime errors

[SandiCat]

It's too bad this issue remains to be fixed. Perhaps the compiler should be iterated upon in tighter cycles. On Feb 17, 2016 12:33 AM, "Sebastian Porto" notifications@github.com wrote:

I'm having the same issue while using https://github.com/rtfeldman/elm-webpack-loader or using elm-make in Sublime I often get successful builds when in reality things are broken resulting in runtime errors

— Reply to this email directly or view it on GitHub https://github.com/elm-lang/elm-make/issues/72#issuecomment-184919714.

[domenkozar]

For cross reference: https://github.com/mybuddymichael/linter-elm-make/issues/32

[evancz]

I think this will be fixed by https://github.com/elm-lang/elm-make/commit/46ec85c0e8dc5f3427bde6e4f212b4f367ecbd07

I guess we should wait to close until we can verify that this is fixed in the 0.18 alpha.

[evancz]

Can anyone confirm that it is fixed by the alpha?

[evancz]

I'm going to close. Open a new thing with an SCCEE if it's still an issue in the 0.18 alpha.