webpack-dev-server configuration

[pschaeflein]

The default settings for webpack-dev-server will display an overlay in the browser when there are warnings. In my scenario, and I’m guessing others in the future, I get a performance warning because the webpack size is larger than the recommended. This happens in development, but not production. That does not seem unreasonable.

However, the overlay shows On. Every. Page. Load. Or. Refresh. 😖

I was able to resolve my issue by updating the configuration in the yoteams-build-core\dist\webpackServe.js file. The following entry suppresses the warnings that frustrate me:

client: {
  overlay: {
    warnings: false,
    error: true
  }
}

Obviously, these changes would be reverted by an update to the package, and would not exist in any new projects I create.

I understand that these changes may not be desirable for all users. So, does it make sense to look for a different config file in the project? Or an entry in the existing webpack.config.js? Or even change the default?

[pschaeflein]

I would like to propose an updated to support a developer-provided configuration file for webpack-dev-server.

The following code would merge any provided configuration with the current settings that are hard-coded:

    const webpackConfig = require(path.join(process.cwd(), "webpack.config"));
    const compiler = Webpack(webpackConfig[1]);

    // notify console that webpack is happening
    compiler.hooks.beforeCompile.tap("webpackServe", () => {
        console.log("webpack compiling")
    });

    const webpackDevServerConfig = optionalRequire(path.join(process.cwd(), "webpack.devServer.config"), true) || {} ;

    const dsOpts = {
        hot: false,
        host: "localhost",
        port: 9000,
        allowedHosts: "all",
        devMiddleware: {
            writeToDisk: true,
            stats: {
                all: false,
                colors: true,
                errors: true,
                warnings: true,
                timings: true,
                entrypoints: true
            }
        }
    }

    lodash.merge(dsOpts, webpackDevServerConfig);
    const server = new WebpackDevServer(dsOpts, compiler);

If this seems reasonable, I can put a PR together.

@wictorwilen @s-KaiNet

[pschaeflein]

https://github.com/pnp/generator-teams/compare/preview...pschaeflein:preview?expand=1

[s-KaiNet]

Strange that you see the performance warning during the development. Are you sure that you're running gulp serve --debug? --debug is critical here, otherwise webpack will use production settings for serve.

Regarding the issue your suggestion looks perfectly valid to me, however, I would make it a bit simpler. Webpack supports the devServer configuration right inside the webpack.config.js. Unfortunately, when you use webpack-dev-server NodeJS API (new WebpackDevServer() here) it does not merge devServer settings and instead overwrite with what is hardcoded in our code. From docs:

If you're using dev-server through the Node.js API, the options in devServer will be ignored

But we can simply merge those settings in our code easily, smth like in the below code:

const webpackConfig = require(path.join(process.cwd(), "webpack.config"));
const feConfig = webpackConfig[1];
const defaultDevServerOpts = {
	hot: false,
	host: "localhost",
	port: 9000,
	allowedHosts: "all",
	.... etc.
};

// if developer provided specific devServer options, then merge them with the default one
if(feConfig.devServer) {
	lodash.merge(defaultDevServerOpts, feConfig.devServer);
}
const compiler = Webpack(feConfig);
const server = new WebpackDevServer(defaultDevServerOpts, compiler);

That way a developer keeps everything in one file and in one configuration.

Additionally, I would make a change to the default overlay setting and make a warning to be disabled, like in your initial fix, ie.:

client: {
  overlay: {
    warnings: false,
    error: true
  }
}

[pschaeflein]

Why is it strange to see the warnings in development? Certainly the dev package is larger than the production one. I just don't want it showing in the browser, just in the console.

[s-KaiNet]

It's strange because if you're in development (webpack's mode=development) then webpack does not generate any performance warnings. You shouldn't see them at all. If you see them, then probably you're running in production mode and all your output JS files are getting minified (which is very slow). That's why I asked whether you use --debug parameter. Depending on this parameter webpack runs in either prod or dev mode (webpack.config.js):

mode: debug ? "development" : "production",

When running serve just check dist/scripts/client.js and check if it's minified. If yes - you're running serve in production mode and you will see all those performance warnings.

Maybe it's not very clear, that you should use --debug with serve, if you want webpack development build. Maybe it makes sense to make it default when we run any serve command.

[pschaeflein]

Ah, so another documentation issue.

The only place I've seen run "--debug" in the docs is here:

And, since I'm not debugging, why would I run --debug?

Seems to me that if devServer is being run, then it should default to this debug mode.

(Assuming there is no reason to run dev server in production.)

[wictorwilen]

Good feedback (we should add more details on the --debug experience). It's however mentioned in the scaffolded README file as well.

[wictorwilen]

What if we added an option, similar to SPFx, where you can modify this in your local webpack and then merge them?

[s-KaiNet]

Do you mean specifying it in the webpack.config.js, ie.:

...plugins: [
        new webpack.EnvironmentPlugin({ PUBLIC_HOSTNAME: undefined, TAB_APP_ID: null, TAB_APP_URI: null }),
        new ForkTsCheckerWebpackPlugin({
            typescript: {
                configFile: "./src/client/tsconfig.json"
            }
        })
    ],
devServer: {
	// developer override for the devServer
}

So that the developer controls which settings to use for DevServer (later will be merged with our settings).

[wictorwilen]

Lol... @s-KaiNet already explained how to do this above - that's what you get from reading this on a mobile phone...

[s-KaiNet]

If everybody agrees, I will make a PR with this change.

[s-KaiNet]

Added #249

[pschaeflein]

I left this note in the PR (multiple times by accident), but I think that PR is premature.

I will start a new "thread" below with what I think the issues are and my thoughts on them. No doubt you folks have thought of them and your answers will be a great start on the docs. ;)

[pschaeflein]

I've renamed this issue to better reflect what I am really asking for. :) Below are the items I feel would help developer understand what is happening and how to best get the application developed.

(I've written them as declarative statements, like a requirement. Please treat them as suggestions/requests.)

I'm using "serve task" to mean both gulp serve and gulp ngrok-serve.

• Remove the --debug setting.

  The best edit/compile/debug experience is achieved using the --debug parameter on the serve task. This should be the default.

• Following the convention used by SPFx, add a parameter named --ship to indicate a build for a production environment.

  The --ship parameter would use the "production" settings for webpack, the "compressed" setting for SASS and omit the "--inspect" setting for nodemon.

• Move the webpack-dev-server defaults to the webpack.config.js file.

  Add the devServer node to the scaffolded webpack.config.js file, including the current defaults from webpackServe.ts.

• Add a begin message to the webpack-dev-server process

  All of the gulp tasks log a begin and completed message. The webpack-dev-server process should do the same. (Currently, logs only completed.)

• Do not run webpack:client during the server task.

  The serve task runs the webpack:client sub task. Then the webpack-dev-server process is invoked.

[pschaeflein]

Thanks for the insights!

Your comments are different from how I interpreted the README file. The serve command is shown in the "Debug and test locally" section, and I mistakenly assumed serve was just for the local experience. (No doubt my Node-based ignorance bleeding thru.)

I do not want to advocate a major change. If gulp serve is how a solution would be run in production, then I agree we should leave that alone.

I still think the last three items are worthwhile. And perhaps an update to the README, because I just now discovered the debug script in package.json, and maybe that is the best way for noobs to get started...

[wictorwilen]

So, this discussions should essentially be split in two parts (how I interpret it).

Documentation: We need to improve the documentation of the debug flag. All tasks are documented here https://github.com/pnp/generator-teams/tree/master/packages/yoteams-build-core and we're also currently doing a big update to the documentation in general (#238)

Customization of webpack dev server configuration: this is where this thread started

[pschaeflein]

Yea, I think so.

I'll dig into 238. Not for the "looks pretty" bits, but to see if I can provided some help to the rest of the C# folks. 😜

[s-KaiNet]

I also thought that gulp serve is for local dev only (that's the SPFx background:)). Thanks for clarifying those bits!
Then I can work on the two points related to the webpack dev configuration:

• default webpack-dev-server settings go to the webpack.config.js, so that it's more clear where to change them for developers
• a message about starting the compilation

Agreed?

[pschaeflein]

Yes on those two.

In addition, if the --debug switch is provided, and the webpack-dev-server will be invoked, I think the "webpack:client" task should be skipped.