DllReferencePlugin should resolve the Dll name as an external library

Do you want to request a feature or report a bug?

This can be considered as a feature

What is the current behavior?

When dealing with a Dll built by webpack on an other project, the dependencies are well resolved. So libraries like


Are found during the built using DllReferencePlugin and its manifest.

And to resolve the custom libraries, the DllReferencePlugin resolves it using the relative paths. Example :


But a DllPlugin comes with a name too, and I think that everything that is exported directly by the Dll should be resolved from its own name. Example, a library named “@my/library” :

new webpack.DllPlugin({
  name: 'mydll',
  context: '.',
  path: helpers.root('dist/core-manifest.json')

should be resolve by the DllPluginReference when the developper mentions :


What is the expected behavior?

In fact, the behavior can be considered as a use of DllReferencePlugin and externals on the same library, see #2875

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

Here you can find a repository wich won’t built successfully, but should illustrate my use case :


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

Webpack 1.* and 2.1.0-beta*
Node v6.9.1

Author: Fantashit

1 thought on “DllReferencePlugin should resolve the Dll name as an external library

  1. Well, after a few hours of digging, I found a solution.

    I used resolve.alias to map require(“mydll”) to require(“./src/dll/index.js”).

    I don’t really like it because it’s a bit tricky to configure webpack, but it does what I need.

    The example can be seen here : vtabary/webpack-require-dllname@0db6bd6 if someone need it.

Comments are closed.