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
lag@0.0.0 /Users/frosas/projects/lag
└── webpack@4.42.0 

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

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]

The goal was to make it easier for plugin writers to modify which tags are injected into the html

The idea behind that is that there would be a single source of truth - headTags are injected into the head and bodyTags are injected in the body.

If the information is hold at two places the plugin writers will always need to keep it in sync.
So this api tried to prevent errors but it looks like it also prevents some features now 🤦‍♂

I would prefer to not add files.chunks again for that reason.
However we might bring it back as a plugin (which would be full backwards compatible) or provide a better api to allow the same features as before.

An api might look like for example like this (would output all Githubissues.

Githubissues is a development platform for aggregating issues.