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

feature

What is the current behavior?

Specifying output file names is not very flexible.

{
output: {
filename: '[name].js'
}
}

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

The current way of specifying output filenames is very limiting. I'm in a situation where (for shitty legacy reasons), I need one of my entry points to always output [name].js, but for all other entry points I want to use [name].min.js in prod and [name].js in dev. I'm not aware of anyway to do this without specifying two webpack configs. It would be great if output.filename could accept either a function that is passed the bundle info ({ hash, name, ... }) and returns a filename, or a map of entry name to filename pattern.

function

{
output: {
filename: (bundle) => {
return `${bundle.name}-foo.js`;
}
}
}

map

{
output: {
filename: {
entry1: '[name].js`,
entry2: '[name].min.js`,
entry3: '[name]-foo.min.js`
}
}

Adding something like this would also allow the use of kebab case names without having to quote your entry names, along with opening up many other opportunities.

{
entry: {
'this-is-my-bundle-name': 'index.js', // meh
thisIsMyBundleName: 'index.js`, // nice
},
output: {
filename: (bundle) => {
return `${_.kebabCase(bundle.name)}.js`;
}
}
}

I'm happy to contribute if this idea is approved.

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

feature

What is the current behavior?

DllPlugin currently only works on library bundles, not entry bundles. That is, it is impossible for a DllPlugin bundle to execute code when it is imported via a script tag into the page, other than to expose its code as a global variable.

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

What is the expected behavior?

DllPlugin should support also running an entrypoint module in addition to exposing the global library variable.

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

My project has a system architecture in which plugins (optional modules) to the system are dynamically enabled by virtue of having a javascript file for the plugin imported into the page. This behavior is non-negotiable in the project for a few reasons, including our testing/CI environment. So, we build one webpack target per plugin, in addition to the webpack target for the core system. Some of these plugins depend on one another at runtime, and we do not wish to duplicate code inside them since we know a priori that they will coexist at runtime and are imported in the correct topologically-sorted order. The DllPlugin solves this nicely, allowing us to declare that modules will be imported at runtime via the manifest lookup. However, plugins are not just libraries, they are bundles with an entry that needs to execute code. We could build two bundles per plugin, one for the library and one for the entrypoint, but that gets messy and has the drawback of being a breaking change for downstream users of the tool.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

webpack version: 2.2