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.
