Html-webpack-plugin: Can't get assets by entry point chunk name in v4

[frosas]

Congrats on the new major version guys.

Expected behaviour

In v3, it was possible to obtain chunk assets by accessing htmlWebpackPlugin.files.chunks[entryName].entry from the template.

Current behaviour

According to https://github.com/jantimon/html-webpack-plugin/blob/master/CHANGELOG.md#breaking-changes there's a breaking change affecting such feature:

The chunks property was removed and the js and css property was converted from a string into an object { entryName: string, path: string}

According to that, one would expect js and css properties in htmlWebpackPlugin.files to contain the mentioned object but I still get the same array of strings as in v3:

{
  ...,
  "files": {
    "publicPath": "",
    "js": [
      "scripts/main.js",
      "scripts/service-worker.js",
      "scripts/ping-worker.js"
    ],
    "css": [
      "styles/main.css"
    ]
  },
  ...
}

## Environment Tell us which operating system you are using, as well as which versions of Node.js, npm, webpack, and html-webpack-plugin. Run the following to get it quickly:

~/projects/lag (dependabot/npm_and_yarn/html-webpack-plugin-4.0.1, Node v12.11.1)
❯ node -e "var os=require('os');console.log('Node.js ' + process.version + '\n' + os.platform() + ' ' + os.release())"
npm --version
npm ls webpack
npm ls html-webpack-plugin
Node.js v12.11.1
darwin 19.3.0

~/projects/lag (dependabot/npm_and_yarn/html-webpack-plugin-4.0.1, Node v12.11.1)
❯ npm --version
npm ls webpack
npm ls html-webpack-plugin
6.13.7

~/projects/lag (dependabot/npm_and_yarn/html-webpack-plugin-4.0.1, Node v12.11.1)
❯ npm ls webpack
npm ls html-webpack-plugin
[email protected] /Users/frosas/projects/lag
└── [email protected] 


~/projects/lag (dependabot/npm_and_yarn/html-webpack-plugin-4.0.1, Node v12.11.1)
❯ npm ls html-webpack-plugin
[email protected] /Users/frosas/projects/lag
└── [email protected] 

Config

Copy the minimal webpack.config.js to produce this issue:

https://github.com/frosas/lag/blob/f82961175485b1540cefc7f48bc251dad83df10b/webpack.config.js#L55-L71

Copy your template file if it is part of this issue:

https://github.com/frosas/lag/blob/f82961175485b1540cefc7f48bc251dad83df10b/html/index.ejs

Additional context

I couldn't find any reference to entryName in the plugin code that suggested the new behavior was actually implemented.

Also, htmlWebpackPlugin.files section in https://github.com/jantimon/html-webpack-plugin/blob/master/README.md seems outdated now.

[jantimon]

unfortunately you are right this is the entire information available inside the template:

https://github.com/jantimon/html-webpack-plugin/blob/2ab27f004ca90a7ab7c949c39ea7371332d70515/index.js#L696-L710

what we could do is to extend the template variable generator:

https://github.com/jantimon/html-webpack-plugin/blob/2ab27f004ca90a7ab7c949c39ea7371332d70515/index.js#L1015-L1045

To provide for example a key value map like

htmlWebpackPlugin.entryFileMapping = {
  'path/to/my/js/file.js': 'main'
}

Or we could iterate over those entries and attach it to the object directly here:

https://github.com/jantimon/html-webpack-plugin/blob/2ab27f004ca90a7ab7c949c39ea7371332d70515/index.js#L387-L390

[frosas]

The original feature seems to be quite popular (https://github.com/search?q=htmlWebpackPlugin.files.chunks&type=Code), would it be possible to maintain backwards compatibility to make the upgrade process as easy as possible to all? Happy to discuss alternatives if not :)

[jantimon]

@kroko I am very sorry but right now <%= htmlWebpackPlugin.chunks is no longer supported anymore as explained here: https://github.com/jantimon/html-webpack-plugin/issues/1369#issuecomment-604382645

I have some solutions in mind but it will take me a moment to implement it (as I am doing that in my spare time).

Thanks for bringing up the issue with the outdated documentation 👍

[kroko]

Sure, I know that the changes are for good, as you have explained it in the comment. Thanks for the great work! 🙇

Just to clarify - what does "not supported" mean given that htmlWebpackPlugin.files does return results (just not the chunks)?
Can htmlWebpackPlugin.files.js and htmlWebpackPlugin.files.css still be used if one does not plan on having some chunk logic (in other words, if there is a case where all compiled assets should be dumped in template without any filtering - as it is with SPA with one entry - then htmlWebpackPlugin.files still can be used)? Or "not supported" means that htmlWebpackPlugin.files key will be removed altogether at some point?

[jantimon]

Sorry for the confusion you are right only chunks was removed.

The new structure is:

https://github.com/jantimon/html-webpack-plugin/blob/c5a58824b8d33c3f9b85d1f541a27844a62721e4/typings.d.ts#L149-L171

The easiest way to output all head tags is:

<%= htmlWebpackPlugin.tags.headTags %>
<%= htmlWebpackPlugin.tags.bodyTags %>

[ghost]

Is this going to change again?

[jantimon]

I will not remove or change the existing structure but probably extend it in some way to allow accessing the chunkname and source of the files to allow inlining again

[hiradyazdan]

I don't know if I am following these commits properly, but it looks like they're not going the way the discussion here was going, and more like the opposite! @jantimon the files.chunks object property was quite useful in earlier versions specially for SPAs. Is this still something you consider rethinking a solution for?

[melyourhero]

Any updates about this issue?