Skip to content

Instantly share code, notes, and snippets.

@jstrimpel
Last active January 5, 2018 17:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jstrimpel/00ff773570a4c44b6d533f44376fdc8b to your computer and use it in GitHub Desktop.
Save jstrimpel/00ff773570a4c44b6d533f44376fdc8b to your computer and use it in GitHub Desktop.

I have two modules A and B. A declares B as a dependency. B is built into a bundle and B's bundle is used as an entry for a DllPlugin bundle. A's build uses the manifest generated by B in a DllReferencePlugin config. I cannot get A's build to externalize and reference B's DLL. Below are the plugin configurations.

A

new webpack.DllReferencePlugin({
  context: 'ABSOLUTE_PATH_TO_B',
  manifest: require('ABSOLUTE_PATH_TO_B/dist/index-manifest')
})

B

new webpack.DllPlugin({
  path: 'ABSOLUTE_PATH_TO_B/dist/index-manifest.json',
  name: `bDll`,
  context: 'ABSOLUTE_PATH_TO_B'
})

The content in B's manifest is relative to B. My assumption is that A's DllReferencePlugin would match B's content when A imports B in A's source because the context is B's absolute path. However, it does not match. What am I doing wrong?

@jstrimpel
Copy link
Author

The solve for this is to always create dependency DLLs, e.g. B, within the context of the top level bundling job (A). Then B's manifest works when A's bundling job encounters, import 'B';. This might seem costly but the DLL bundling for B is really light - B was already transpiled and bundled, so it just wraps it. I do have to trace the dependency graph, but DLLs for my use case follow a naming convention, so it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment