<p dir="auto"><strong>Do you want to request a <em>feature</em> or report a <em>bug</em>?</strong></p>
<p dir="auto">feature</p>
<p dir="auto"><strong>What is the current behavior?</strong></p>
<p dir="auto">Specifying output file names is not very flexible.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{
    output: {
        filename: '[name].js'
    }
}"><pre class="notranslate"><code class="notranslate">{
    output: {
        filename: '[name].js'
    }
}
</code></pre></div>
<p dir="auto"><strong>If this is a feature request, what is motivation or use case for changing the behavior?</strong></p>
<p dir="auto">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 <code class="notranslate">[name].js</code>, but for all other entry points I want to use <code class="notranslate">[name].min.js</code> in prod and <code class="notranslate">[name].js</code> in dev. I'm not aware of anyway to do this without specifying two webpack configs. It would be great if <code class="notranslate">output.filename</code> could accept either a function that is passed the bundle info (<code class="notranslate">{ hash, name, ... }</code>) and returns a filename, or a map of entry name to filename pattern.</p>
<h4 dir="auto">function</h4>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{
    output: {
        filename: (bundle) =&gt; {
            return `${bundle.name}-foo.js`;
        }
    }
}"><pre class="notranslate"><code class="notranslate">{
    output: {
        filename: (bundle) =&gt; {
            return `${bundle.name}-foo.js`;
        }
    }
}
</code></pre></div>
<h4 dir="auto">map</h4>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{
    output: {
        filename: {
            entry1: '[name].js`,
            entry2: '[name].min.js`,
            entry3: '[name]-foo.min.js`
    }
}"><pre class="notranslate"><code class="notranslate">{
    output: {
        filename: {
            entry1: '[name].js`,
            entry2: '[name].min.js`,
            entry3: '[name]-foo.min.js`
    }
}
</code></pre></div>
<p dir="auto">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.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{
    entry: {
        'this-is-my-bundle-name': 'index.js', // meh
        thisIsMyBundleName: 'index.js`, // nice
    },
    output: {
        filename: (bundle) =&gt; {
            return `${_.kebabCase(bundle.name)}.js`;
        }
    }
}"><pre class="notranslate"><code class="notranslate">{
    entry: {
        'this-is-my-bundle-name': 'index.js', // meh
        thisIsMyBundleName: 'index.js`, // nice
    },
    output: {
        filename: (bundle) =&gt; {
            return `${_.kebabCase(bundle.name)}.js`;
        }
    }
}
</code></pre></div>
<p dir="auto">I'm happy to contribute if this idea is approved.</p>
<p dir="auto"><strong>Do you want to request a <em>feature</em> or report a <em>bug</em>?</strong></p>
<p dir="auto">feature</p>


<p dir="auto"><strong>What is the current behavior?</strong></p>
<p dir="auto">DllPlugin currently only works on <code class="notranslate">library</code> 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.</p>
<p dir="auto"><strong>If the current behavior is a bug, please provide the steps to reproduce.</strong></p>



<p dir="auto"><strong>What is the expected behavior?</strong></p>
<p dir="auto">DllPlugin should support also running an entrypoint module in addition to exposing the global library variable.</p>
<p dir="auto"><strong>If this is a feature request, what is motivation or use case for changing the behavior?</strong></p>
<p dir="auto">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 <em>a priori</em> 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 <code class="notranslate">entry</code> 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.</p>
<p dir="auto"><strong>Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.</strong></p>
<p dir="auto">webpack version: 2.2</p>