Skip to content
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

Webpack v4 and v4-beta support #1295

Closed
1 of 2 tasks
lencioni opened this issue Jan 29, 2018 · 11 comments
Closed
1 of 2 tasks

Webpack v4 and v4-beta support #1295

lencioni opened this issue Jan 29, 2018 · 11 comments

Comments

@lencioni
Copy link
Contributor

  • This is a bug
  • This is a modification request

Now that webpack v4-beta.0 has been released, there are no more expected breaking changes before the v4 full release in a few weeks. It would be great to publish a version of webpack-dev-server that aims to add support for this new version so folks can start to test their stuff.

I found #1243 which could be a good start for this, but I figured I'd open an issue for folks to track if they are interested in this in general.

@dschissler
Copy link

I've been caught twice now trying to upgrade Webpack during late beta and getting through the config changes only to realize that it was a waste of time since webpack-dev-server wasn't yet supported. This happened to me on v1 -> v2 and now v3 -> v4.

I have a question if the serious developers are not using dev-server in their big projects because I can't see how it would be ideal to do a final beta when the two haven't yet been tested together to see if there are unforeseen limitations. The dev-server isn't as first class as I'd like. I guess that for now I'll just set this code aside, rollback, remove npm links. Its annoying.

@drwpow
Copy link

drwpow commented Feb 10, 2018

I’m having an issue with code-splitting in v4-beta + WDS (in addition to the fun yargs issue mentioned).

Code-splitting is trying to load chunks relatively from the path it’s on, rather than absolutely from the root. E.g., if you’re on /pages/about, the chunk is 404-ing trying to load from /pages/1.js rather than /1.js like v3 did.

Not sure if this is a WDS issue or a webpack v4 issue.

Example here: https://github.com/dangodev/webpack-v4-code-splitting-test

@damonbauer
Copy link

@DangoDev This was just posted a few hours ago, it might be related: https://medium.com/webpack/webpack-4-import-and-commonjs-d619d626b655

@drwpow
Copy link

drwpow commented Feb 14, 2018

@damonbauer nice! Just read through that. That’s helpful info, but I don’t think that’s affecting this issue.

I opened an issue on the core repo. I’m thinking now it’s a webpack thing, not a webpack-dev-server thing.

@SpaceK33z
Copy link
Member

Please test the latest beta, webpack-dev-server@3.0.0-beta.1. Also be sure to read the changelog.

@drwpow
Copy link

drwpow commented Feb 14, 2018

@SpaceK33z when passing arguments via CLI (e.g., "start": "webpack-dev-server --hot"), it seems to require installing webpack-cli for yargs. Is this intentional, or a bug?

@SpaceK33z
Copy link
Member

It intentionally requires webpack-cli, yes.

@esamattis
Copy link

Found couple of issues with the new defaults in Webpack 4.

Versions:

  • webpack-dev-server 3.0.0-beta.1
  • webpack 4.0.0-beta.1

Config:

var config = {
    mode: "development",
    module: {
        rules: [
            {
                test: /\.jsx?$/,
                exclude: /node_modules/,
                loader: "babel-loader",
            },
        ],
    },
};

As the entry is not defined following error is thrown:

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.entry should be one of these:
   object { <key>: non-empty string | [non-empty string] } | non-empty string | [non-empty string] | function
   -> The entry point(s) of the compilation.
   Details:
    * configuration.entry should be an object.
      -> Multiple entry bundles are created. The key is the chunk name. The value can be a string or an array.
    * configuration.entry should be a string.
      -> An entry point without name. The string is resolved to a module which is loaded upon startup.
    * configuration.entry[1] should be a string.
      -> A non-empty string
    * configuration.entry should be an instance of function
      -> A Function returning an entry object, an entry string, an entry array or a promise to these things.

It works if I define it to entry: "./src/index.js" but that should not be required with Webpack 4 as it's the default.

Another related thing is that the bundle should be served from /dist/main.js. It seems that it's not served at all. This can be fixed by setting:

output: {
    publicPath: "/dist",
},

But it's useable otherwise. Thank you!

@SpaceK33z
Copy link
Member

@epeli do you also get this error when you are using webpack instead of webpack-dev-server?

@esamattis
Copy link

Nope, the weppack command works as expected.

@SpaceK33z
Copy link
Member

SpaceK33z commented Feb 16, 2018

@epeli see #1308 for that error.

I'm going to close this since the latest beta works with webpack v4 now. Let's create separate issues for new problems.

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

6 participants