serveIndex is now serving wrong directory if having multiple paths in contentBasePublicPath

[LuckyWindsck]

• Operating System: macOS Mojave (Version 10.14.6)
• Node Version: v14.4.0
• NPM Version: 6.14.4（I used yarn)
• Yarn Version: 1.22.4
• webpack Version: 4.43.0
• webpack-dev-server Version: 3.11.0
• Browser: Version 83.0.4103.97 (Official Build) (64-bit)

• This is a bug
• This is a modification request

Code

Repository link if needed.

// webpack.config.js
const path = require('path');

module.exports = {
  devServer: {
    open: true,
    openPage: [ 'static1', 'static2', 'static3' ],
    contentBase: [ path.join(__dirname, 'static1'), path.join(__dirname, 'static2'), path.join(__dirname, 'static3') ],
    contentBasePublicPath: [ '/static1', '/static2', '/static3' ],
  }
}

// Directory structure
$ tree -I "node_modules"                      
.
├── package.json
├── src
│   └── index.js
├── static1
│   ├── s1-dir1
│   │   └── index.html
│   ├── s1-dir2
│   │   └── index.html
│   └── s1-dir3
│       └── index.html
├── static2
│   ├── s2-dir1
│   │   └── index.html
│   ├── s2-dir2
│   │   └── index.html
│   └── s2-dir3
│       └── index.html
├── static3
│   ├── s3-dir1
│   │   └── index.html
│   ├── s3-dir2
│   │   └── index.html
│   └── s3-dir3
│       └── index.html
├── webpack.config.js
└── yarn.lock

13 directories, 13 files

Expected Behavior

When running webpack-dev-server, three pages should be opened.
They should be the following links respectively:

• http://localhost:8080/static1/
• http://localhost:8080/static2/
• http://localhost:8080/static3/

Also, since devServer.serveIndex is true by default, these pages should list the directory structure of ./static1, ./static2, ./static3 with the same structure as the actual directory .

Actual Behavior

• http://localhost:8080/static1/
  
• http://localhost:8080/static2/
  
• http://localhost:8080/static3/
  

For Bugs; How can we reproduce the behavior?

Just run webpeck-dev-server (version 3.11.0), and one should be able to reproduce this behavior.

For Features; What is the motivation and/or use-case for the feature?

[LuckyWindsck]

Actually, I have read the lib/Server.js, and found the pull request and the code snippet for this bug.

Pull Request: #2489 (Modified setupStaticFeature)

In this PR, contentBasePublicPath accepts multiple paths. It actually does, I can access the following links (status code 200):

• http://localhost:8080/static1/s1-dir1/
• http://localhost:8080/static2/s2-dir2/
• http://localhost:8080/static3/s3-dir3/

However, in the following snippet, contentBasePublicPath is also used but not modified in the PR.

Code snippet:

// ...
setupServeIndexFeature() {
// ...
  if (Array.isArray(contentBase)) {
    contentBase.forEach((item) => {
      this.app.use(contentBasePublicPath, (req, res, next) => {
        // serve-index doesn't fallthrough non-get/head request to next middleware
        if (req.method !== 'GET' && req.method !== 'HEAD') {
          return next();
        }

        serveIndex(item, { icons: true })(req, res, next);
      });
    });
  }
// ...
}
// ...

If devServer.contentBasePublicPath is an array, it seems like serve-index will list all pages by the directory structure of the zeroth element (./static1), thus what I showed in the Actual Behavior.

[LuckyWindsck]

Other problem

I am not sure if I should create a new issue or not, but anyway, let me write them down first.

Should cover all possibilities of combining options together

I tried to list a table by only checking the code. (Sorry, I don't have extra time to test them now.)

setupStaticFeature

contentBase	contentBasePublicPath	Current Behavior
boolean: false	string / [string]	working, not pushed into runnableFeatures
number	string / [string]	working, showing deprecated
string	string	working
string	[string]	not working and not implemented
[string]	string	working
[string]	[string]	working

setupServeIndexFeature

contentBase	contentBasePublicPath	Current Behavior
boolean: false	string / [string]	working, not pushed into runnableFeatures
number	string / [string]	working, doing nothing
string	string	working
string	[string]	not working and not implemented
[string]	string	working
[string]	[string]	not working and not implemented

setupWatchStaticFeature

contentBase	watchContentBase	Current Behavior
any	false	working, not pushed into runnableFeatures
boolean: false	true	potential problem running chokidar.watch(false, watchOptions)
number	true	working, throwing error
string	true	working
[string]	true	working

Should remove duplicate features in runnableFeatures

In setupFeatures, there is possibility to produce duplicated elements in runnableFeatures. It might be a potential problem.

[alexander-akait]

WIP for v4, no fixed for v3, sorry

[LuckyWindsck]

Do you mean the following tasks? Also, when will v4 be released?

[alexander-akait]

Yes, no ETA, maybe end of the month

[alexander-akait]

@LuckyWindsck Can you try beta-0?

[alexander-akait]

Fixed in beta-0, now you can setup publicPath for the each statis https://github.com/webpack/webpack-dev-server/blob/master/lib/options.json#L15 (they can be not only one), feel free to feedback

[LuckyWindsck]

@alexander-akait

Sorry for late reply.
I was not familiar with the GitHub notification system so I miss your mention.
I just tried v4.0.0-beta.0 and it worked perfectly for my case.
Thank you very much.

$ git diff issue-opened:webpack.config.js issue-resolved:webpack.config.js

http://[::]:8080/static1/

http://[::]:8080/static2/

http://[::]:8080/static3/