
The Symfony team recently came up with full webpack support togehter with the @symfony/webpack-encore module.
Webpack-encore supports both the webpack-dev-server with HMR and versioning. The asset library then picks up the real generated file without requiring you to change your import statements using the manifest.json file.
More info:
- http://symfony.com/doc/current/frontend/encore/versioning.html#load-mani...
- http://symfony.com/doc/current/frontend/encore/dev-server.html
It might be usefull to support the manifest.json file in a themes libraries.yml file aswell.
Is this something that would be accepted? Should this be solved differently?
Comments
Comment #2
pinoniq CreditAttribution: pinoniq commentedComment #5
elendev CreditAttribution: elendev at Swissquote commentedThis is a really good idea.
A solution I use right now is to avoid the version key in the my-module.libraries.yml files, this way we avoid having cache issues on the visitors when a library is updated (and in case we forgot to update manually the version field).
The problem with this approach is that a new version number is generated every time the cache is cleared, leading to useless libraries downloads from the visitors.
Adding a manifest field in the my-module.libraries.yml might solve that:
This is only an example on how it could be implemented. With this field, Drupal would get the generated my-lib.min.js file (example: my-lib-abc123456.min.js) instead of the non-existing my-lib.min.js.
Comment #8
pasqualleComment #9
pasqualleComment #10
nod_Comment #15
yoerioptr CreditAttribution: yoerioptr commentedI recently ran into the same issue. My workaround consists of implementing
hook_library_info_alter()
that replaces the asset source with the destination within a definedmanifest.json
and looks something like this.This allows you to define a
manifest.json
path which will be used when the caches get rebuilt. Thelibraries.yml
looks something like this.Here is an example
manifest.json