Unclear config issue when using API? "Error: Invalid path"

[scvnc]

Repo replicating the issue: https://github.com/scvnc/webpack-dev-server-grief

My webpack config seems to be configured correctly because running the CLI webpack-dev-server is successful. However when using the gulp example from the webpack docs: I can't seem to successfully invoke the webpack dev server. What is going on?

$ npm install
$ gulp
[10:35:59] Using gulpfile ~/webpack-dev-server-grief/gulpfile.js
[10:35:59] Starting 'default'...
[10:35:59] Finished 'default' after 49 ms
[10:35:59] [webpack-dev-server] http://localhost:8080/index.html

/home/vincent/webpack-dev-server-grief/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:161
            if(isError) throw e;
                              ^
Error: Invalid path
    at pathToArray (/home/vincent/webpack-dev-server-grief/node_modules/webpack-dev-server/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:23:38)
    at MemoryFileSystem.mkdirpSync (/home/vincent/webpack-dev-server-grief/node_modules/webpack-dev-server/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:107:13)
    at MemoryFileSystem.(anonymous function) [as mkdirp] (/home/vincent/webpack-dev-server-grief/node_modules/webpack-dev-server/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:187:34)
    at Tapable.<anonymous> (/home/vincent/webpack-dev-server-grief/node_modules/webpack/lib/Compiler.js:225:25)
    at Tapable.applyPluginsAsync (/home/vincent/webpack-dev-server-grief/node_modules/webpack/node_modules/tapable/lib/Tapable.js:60:69)
    at Tapable.Compiler.emitAssets (/home/vincent/webpack-dev-server-grief/node_modules/webpack/lib/Compiler.js:222:7)
    at Watching.<anonymous> (/home/vincent/webpack-dev-server-grief/node_modules/webpack/lib/Compiler.js:53:18)
    at /home/vincent/webpack-dev-server-grief/node_modules/webpack/lib/Compiler.js:397:12
    at Tapable.next (/home/vincent/webpack-dev-server-grief/node_modules/webpack/node_modules/tapable/lib/Tapable.js:69:11)
    at CachePlugin.<anonymous> (/home/vincent/webpack-dev-server-grief/node_modules/webpack/lib/CachePlugin.js:40:4)

[sokra]

    output: {
        library: '[name]',
        filename: './build/js/[name].js'
    },

should be

    output: {
        path: require("path").resolve("./build/js"),
        library: '[name]',
        filename: '[name].js'
    },

[scvnc]

Ah thanks! I also looked deeper and noticed that the webpack-dev-middleware readme indicates that output.path needs to be set. Perhaps it could default to '/' as it is suggested in the readme. Granted it looks like having the path explicitly defined is a good practice for my use case anyways.

[sokra]

I assume the leading ./ in output.filename was the problem.

[scvnc]

The leading ./ may have been part of the problem. I think it was more of a bad practice on my part. Note that I have been able to develop just fine using the leading ./ in the config while using the webpack-dev-server CLI.

I have simplified my issue repo to demonstrate the issue without the ./

This still causes problems

output: {
    library: '[name]',
    filename: '[name].js'
},

This solves the problem

output: {
    path: '/whatever/anything',
    library: '[name]',
    filename: '[name].js'
},

I suspect that this is because the path is a psudo-required configuration property. Per the webpack-dev-middleware usage example:

output: {
    path: "/"
    // no real path is required, just pass "/"
    // but it will work with other paths too.
}

It seems that the webpack-dev-server CLI automatically defaults this in bin/webpack-dev-server.js but there is no such default value when using the webpack-dev-server API.

I could suggest adding in a line in the webpack-dev-middleware. It seems to work in my tests but I'm not confident of what effects it might have.

[amir-rahnama]

@sokra @scvnc I came across the issue and the leading ./ was the issue but why the webpack core package doesn't reflect on it and the dev server is throwing the error only? Isn't it inconsistent?

[CoolGoose]

Same issue here, using the proposed fix from @sokra

 path: require("path").resolve("./build/js"),

works like a charm.
Any way for a nicer error output ?

[0x80]

This just cost me a few hours of frustration trying to move an existing project from dev server to middleware. A validation of output.path and a little more descriptive error would be very welcome.

[cchamberlain]

I just started getting this with webpack-hot-middleware today and the cause was a recent refactor of my webpack config builder to es6, now using export default.

Fix for me was to change require('../webpack.config') to require('../webpack.config').default in my server code that wires up the hot middleware. Boils down to the same issue with not having a path set, would be good to have an assert in webpack with a more useful message.

[zedd45]

I encountered this issue trying to find the middle-ground for :global / and :local for CSS modules styles, based on @sokra's comments, here:
css-modules/css-modules#59 (comment)

I did not modify path nor publicPath for my output for this task (nor for some time), but I do believe another misconfiguration on my part caused this same error (and thus led me to this post).

In my case, I was importing a stylesheet that had previously been local to a container component, but I switched the stylesheet to be global by default, and my build failed with the same error message.

I believe my include (preferred) / exclude logic may have been to blame for this (webpack likely could no longer parse this file). I was experimenting with this feature, and restructuring my CSS locally.

[SpaceK33z]

#337 was fixed in the latest beta release. This means that the dev-server CLI does no longer overwrite output.path to /, making the error the author initially had less weird.

I'll look into having some validation for output.path, if I can find some cases where it is always incorrect.

[SpaceK33z]

webpack-dev-middleware should now give a proper error when using a relative path;
webpack/webpack-dev-middleware@ee9b796