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

Shared content base for multiple compiler instances #1283

Closed
just-boris opened this issue May 28, 2022 · 6 comments
Closed

Shared content base for multiple compiler instances #1283

just-boris opened this issue May 28, 2022 · 6 comments

Comments

@just-boris
Copy link

just-boris commented May 28, 2022

Modification Proposal

We have the following webpack config:

module.exports = ["foo", "bar"].map((theme) => {
  return {
    entry: "./src/index.js",
    output: {
      path: path.resolve(`dist/${theme}`),
    },
    resolve: {
      alias: {
        "~current-theme": path.resolve(`./src/themes/${theme}`),
      },
    },
  };
});

Webpack 4 handles such config perfectly allowing to see both themes on a single server via (/foo/main and /bar/main). With webpack 5 it no longer works (there is a single theme at /main).

This happened because of changes in getPaths implementation. Previously it allowed loose path matches.

Expected Behavior / Situation

There is a configuration option to set the base path for all entry points, so files will be resolved properly against each compiler

Actual Behavior / Situation

Currently there is no way to serve multiple compilations from a single server.

I created a demo project to with minimal scenario for this issue: https://github.com/just-boris/webpack-multi-entries/tree/webpack-5

Please paste the results of npx webpack-cli info here, and mention other relevant information

  System:
    OS: macOS 12.4
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 53.78 MB / 16.00 GB
  Binaries:
    Node: 14.19.2 - ~/n/bin/node
    Yarn: 1.22.15 - ~/n/bin/yarn
    npm: 6.14.17 - ~/n/bin/npm
  Browsers:
    Chrome: 101.0.4951.64
    Firefox: 91.9.0
    Safari: 15.5
  Packages:
    webpack: ^5.72.1 => 5.72.1
    webpack-cli: ^4.9.2 => 4.9.2
    webpack-dev-server: ^4.9.0 => 4.9.0
@alexander-akait
Copy link
Member

It is potential unsafe, that is why it was changed, you can have the same URL for different files here, why you need it?

@just-boris
Copy link
Author

As in my demo repository, the output is in two separate subfolders (/foo and /bar), so there will be no files collision. If output subfolders overlap (/foo and /foo/bar), that's a problem in any way because webpack build would overwrite the files.

Dev server here is a reflection of the output of the normal build, does not need any additional validations

@alexander-akait
Copy link
Member

In theory we can implement overriding outputPath, so you can override it for any numbers of compiles, I don't want to support it by default, because it is really unsafe

@just-boris
Copy link
Author

just-boris commented May 30, 2022

How is this more unsafe than the webpack build output, which produces the same files on the disk? Does it print a warning when overwriting a file from another compiler?

In any way, would you accept a PR adding contentBase property to the middleware options? (I think, it should belong here)

@alexander-akait
Copy link
Member

How is this more unsafe than the webpack build output, which produces the same files on the disk? Does it print a warning when overwriting a file from another compiler?

The main problem here is the same URLs, you can potential create situation when the same URL returns different content, but if you use different directories (like in your example) you should not have these problems

In any way, would you accept a PR adding contentBase property to the middleware options? (I think, it should belong here)

It is not related to contentBase, I think we need better name here, but yes, PR welcome, we will improve name in a PR

@alexander-akait
Copy link
Member

les't close in favor #979, we want to move webpack-dev-middleware into webpack-dev-server (monorepo), so we do some cleaup before moving issues, yeah, I agree, we don't have good support for multi compiler mode and share assets between them

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