Issue 1:
Do you want to request a feature or report a bug?

Feature.

What is the current behavior?

Webpack configuration happens per bundle, this means it's on a per-output basis.

What is the expected behavior?

Configuration would be way more flexible if it provided an additional per-entry configuration.

If this is a feature request, what is motivation or use case for changing the behavior?

My Use Case

I'm working with a CMS at my job. It's suitable for the needs of our clients but it lacks some modern features including asset bundling. So I started working on kind of a webpack-based asset pipeline for that CMS.

The CMS makes use of third-party plugins. Those might bring their own assets so I want to provide a way to bundle those together with the CMS' "main assets".

Giving each plugin its own entry point is easy. But those plugins can get quite big. They may be small applications themselves and might require custom aspects of configuration e.g. their own aliases or loaders.

A plugin might want to define some custom aliases and those should be usable from inside the plugin while not affecting other CMS plugins for obvious reasons—they are probably created by other developers who are not aware of my plugin. These devs could not rely on webpack working in a certain way if my plugin-created configuration could "escape" its scope.

Currently this kind of encapsulated behaviour is not possible in webpack.

The Essence

This mostly boils down to one aspect: One configuration per output makes the bundler only partially suitable for projects where you don't have full control over the assets' source code.

Being able to add per-entry configurations would make webpack much more useful in very loosely coupled projects with independent (and agnostic-of-each-other) developers.

So that would essentially mean to be able to mix multiple webpack configurations into a single output.

Implementation

A naïve approach to adding this idea to the configuration API would be to allow the values of the entry object to be themselves objects:

// To be honest, this looks awful #pyramidofdeath
{
entry: {
myEntry: {
files: [ 'foo.js', 'bar.js' ],
config: {
resolve: {
alias: {
myAlias: '/actual/path'
}
}
}
}
}
}

Let's for now agree on calling each of these embedded config objects a "per-entry configuration" while the surrounding object is the "main configuration".

Requirements and Ideas

Per-entry configurations

should be able to use a shared set of modules.

Multiple entries might access the same modules. That's the main reason why the simplest approach for my case wouldn't work: Bundling the CMS plugins individually and then bundle the resulting bundles together would mean a huge waste by using duplicate code.

should support a sensible subset of the webpack configuration

Aliases, loaders and resolution roots would be useful while having an entry or output option would not make too much sense.

should extend the main confguration in the spirit of @bebraw's very own webpack-merge.

Existing aliases may be extended by custom ones, maybe even overridden.

may only apply to their respective entry and neither affect the main configuration nor other entry configurations

This means overriding main configuration options in an entry configuration will not be applied to anything outside the entry.

Reality Check

While this would (as shown above) not need too extensive changes in the configuration API it would certainly be some immense work under the hood (which @TheLarkInn confirmed when I mentioned my thoughts on twitter). Just to mention that I'm aware of this being a heavyweight suggestion.

It would also bring a load of non-trivial conceptual work e.g. deciding what configuration would be applied to an asset that is used from multiple entry points.

I'm curious to hear about your thoughts on this.

Issue 2:
Bug report

What is the current behavior?

Production build in webpack 5 takes approximatly 20% more time to complete than in webpack 4. Turn minimization off via optimization.minimize makes webpack 5 actually faster then webpack 4.

Providing result of 10 build runs by webpack 4 and by webpack 5:

webpack 4: 6.135080679988861 seconds
webpack 5: 7.854557122190793 seconds

If the current behavior is a bug, please provide the steps to reproduce.

Repo for reproducing https://github.com/SkReD/webpack5-performance-issue

What is the expected behavior?

Build time is bigger about 0 - 5% maximum. Should be possible to configure optimization for reducing build time to webpack 4 values.

Other relevant information:

webpack version: 5.38.1

Node.js version: 16.3.0 (--cpu-profile fails on current LTS)

Operating System: windows 10 x64

Additional tools:

Providing logs of last runs from bench run

webpack 4 profile logs

main-process.cpuprofile

child-process.cpuprofile

webpack 5 profile logs

main-process.cpuprofile

child-process.cpuprofile