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

require('@angular/core');
require('extend');

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 :

require('./src/my-lib.js');

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 :

require('mydll')

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 :

https://github.com/vtabary/webpack-require-dllname

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.