Skip to content

"Error: invalid argument" when starting server with 2.1.0-beta.3 #595

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
EvHaus opened this issue Sep 6, 2016 · 6 comments
Closed

"Error: invalid argument" when starting server with 2.1.0-beta.3 #595

EvHaus opened this issue Sep 6, 2016 · 6 comments

Comments

@EvHaus
Copy link

EvHaus commented Sep 6, 2016

I'm submitting a bug report

webpack and webpack-dev-server version:
webpack: 2.1.0-beta.21
webpack-dev-server: 2.1.0-beta.3

Please tell us about your environment:
OSX 10.11.6

Current behavior:

When running the webpack-dev-server, I get this error:

webpack-dev-server --hot --progress --history-api-fallback --config webpack/webpack.dev.config.js --content-base html/

 http://localhost:8080/
webpack result is served from /build/
content is served from /Users/evgueni.naverniouk/Git/ux/html
404s will fallback to /index.html
webpack: wait until bundle finished: /build/app.js

/Users/evgueni.naverniouk/Git/ux/node_modules/webpack-dev-middleware/middleware.js:106
            if(err) throw err;
                    ^
Error: invalid argument
    at pathToArray (/Users/evgueni.naverniouk/Git/ux/node_modules/memory-fs/lib/MemoryFileSystem.js:44:10)
    at MemoryFileSystem.mkdirpSync (/Users/evgueni.naverniouk/Git/ux/node_modules/memory-fs/lib/MemoryFileSystem.js:139:13)
    at MemoryFileSystem.(anonymous function) [as mkdirp] (/Users/evgueni.naverniouk/Git/ux/node_modules/memory-fs/lib/MemoryFileSystem.js:279:34)
    at Compiler.<anonymous> (/Users/evgueni.naverniouk/Git/ux/node_modules/webpack/lib/Compiler.js:266:25)
    at Compiler.applyPluginsAsync (/Users/evgueni.naverniouk/Git/ux/node_modules/tapable/lib/Tapable.js:73:70)
    at Compiler.emitAssets (/Users/evgueni.naverniouk/Git/ux/node_modules/webpack/lib/Compiler.js:263:7)
    at Watching.onCompiled (/Users/evgueni.naverniouk/Git/ux/node_modules/webpack/lib/Compiler.js:55:18)
    at /Users/evgueni.naverniouk/Git/ux/node_modules/webpack/lib/Compiler.js:442:12
    at next (/Users/evgueni.naverniouk/Git/ux/node_modules/tapable/lib/Tapable.js:81:11)
    at Compiler.<anonymous> (/Users/evgueni.naverniouk/Git/ux/node_modules/webpack/lib/CachePlugin.js:61:4)

Expected/desired behavior:

Server should not fail to start.

This issue was not happening with 2.1.0-beta.0. Only started happening after upgrading to 2.1.0-beta.3

@SpaceK33z
Copy link
Member

SpaceK33z commented Sep 6, 2016

What happens when you set output.path to "/" in your webpack config?

If that doesn't work, could you try upgrading to 2.1.0-beta.2 and see if it also happens there?

@EvHaus
Copy link
Author

EvHaus commented Sep 6, 2016

Changing the output.path to / did not help resolve the issue.

Downgrading to 2.1.0-beta.2 makes the error go away. So looks like it was something introduced between beta.2 and beta.3

@SpaceK33z
Copy link
Member

I can't reproduce your issue yet. Could you post a webpack config here? As minimal as possible please, so I can test it myself easily.

@EvHaus
Copy link
Author

EvHaus commented Sep 7, 2016

Sorry, I take back my previous statement. Changing output.path to / does indeed make the issue go away. My original output.path was set to ./html/build/.

Here is a minimal webpack.config.js that can be used to reproduce the issue:

module.exports = {
    entry: {
        app: ['./html/js/menu.js']
    },
    module: {
        loaders: [
            {test: /\.js$/, loader: 'babel'}
        ]
    },
    output: {
        path: './html/build/',
        publicPath: '/build/',
        filename: '[name].js'
    }
};

@SpaceK33z
Copy link
Member

SpaceK33z commented Sep 7, 2016

Aha. output.path can't have ./. It should be an absolute path. Also see #88 about that. I'm upping the prio of that ticket, because this issue will occur more now. I'll update the changelog to specifically mention that output.path should be an absolute path.

Previously, this wasn't an issue because the CLI overrode the output.path to be /. This was also covered in the CHANGELOG as a breaking change.

@EvHaus
Copy link
Author

EvHaus commented Sep 7, 2016

Confirmed. Using an absolute path resolves the issue. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants