search

GoogleChromeLabs / tooling.report

tooling.report a quick way to determine the best build tool for your next web project, or if tooling migration is worth it, or how to adopt a tool's best practice into your existing configuration and code base.
https://tooling.report
Apache License 2.0
848 stars 49 forks source link

Add test for hashes manifest file(s) creation #370

Open nhoizey opened 4 years ago

nhoizey commented 4 years ago

I see in https://bundlers.tooling.report/non-js-resources/service-worker/ that the list of hashed resources is available for the Service Worker:

The hashed URLs for all assets and the HTML page itself are exposed to sw.js, though the mechanism for this varies between tools.

It would be nice adding a test to know if the bundler can generate a manifest file with such data, when we want to use it in another tool.

I, for example, run first Rollup and then Eleventy. I had to use the rollup-plugin-entrypoint-hashmanifest plugin (thanks @surma!) for the JS hashes manifests (even if there's an issue with multiple builds), and create my own manifest for CSS hashes.

jakearchibald commented 4 years ago

It kinda feels like the service worker test covers the underlying mechanisms to do this. We need to be careful that we don't end up with 10 tests that are checking the same functionality. But maybe this is a common enough pattern to document. Hmm.

nhoizey commented 4 years ago

I don't know if this is common enough, indeed.

However, it looks like the service worker test covers the underlying mechanism (having a list of hashed assets), but not the creation of a file with this content.