I'm not certain of your configuration, but in our current project we pretty much use the standard:
// This loader can be in commonConfig or the production/development section seperately. module: { loaders: [ { test: /\.elm$/, exclude: [/elm-stuff/, /node_modules/], loader: 'elm-hot!elm-webpack' } // our other loaders here ]}; I assume that's your loader. In your package.json, you should have something like "devDependencies":{ "elm": "^0.18.0", "elm-hot-loader": "^0.5.4", "elm-webpack-loader": "^4.1.1", "webpack": "^1.14.0", "webpack-dev-server": "^1.16.2", "webpack-merge": "^2.0.0" //just an example of the basic required packages } The above is what I can look at on a personal project where I have upgraded those modules manually without issue. The rest of the packages are the same as the starter with the exception of a few tweaks to change from bootstrap to semantic-ui, and I guess less-loader. If you're just using the standard elm-webpack-starter, then you should only need to set it as a query on the loader. I personally just installed the 0.18 package globally from the executable from elm-lang.org. If you don't want to do that, then just edit your loader so that it looks like this: //for development build { test: /\.elm$/, exclude: [/elm-stuff/, /node_modules/], loader: 'elm-hot!elm-webpack?pathToMake=node_modules/.bin/elm-make' } //for production build { test: /\.elm$/, exclude: [/elm-stuff/, /node_modules/], loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make' } Just double check and see that your packages were installed/upgraded through npm. I can't tell you how often I frustrate myself when I decide to upgrade a package for a new feature/bug fix and I continue to expect it to work without having actually done anything besides save the package change in package.json. The only other thing that I can think of that could be an issue is if you have globally installed 0.17 and that package is not upgraded to 0.18. Because I don't remember npm commands, the quick reference would just be npm upgrade -g elm That assumes you are using npm 3+ rather than installing the executable from the elm-lang website. As for what Martin and Simon have said, I've noticed that elm-hot-loader only seems to catch your top level changes. Basically, it requires that your file structure be flat to pick up changes consistently. Was that your experience? I would love for elm-hot-loader to catch a few nested folders we have, but playing around with the configuration didn't seem to help. On Thursday, December 22, 2016 at 12:41:44 PM UTC-6, Rex van der Spuy wrote: > > It's possible that your elm-webpack-loader is pointing to the wrong >> executable. >> > > Thanks Nathan! Everything else seem fine so it seems that this is likely > the problem. > Do you know where this needs to be set? > I noticed this from the README in elm-webpack-loader but I wasn't sure > where or how it should be set (in webpack.config.js?) > > ``` > All options are sent down as an `options` object to node-elm-compiler. For > example, you can explicitly pick the local `elm-make` binary by setting the > option `pathToMake`: > > ```js > ... > loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make', > ... > ``` > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.