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:

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

pinoniq created an issue. See original summary.

pinoniq’s picture

Issue summary: View changes

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Elendev’s picture

This 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:

some-lib:
  manifest: js/manifest.json
  js:
    js/dist/my-lib.min.js: {}

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.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Pasqualle’s picture

Title: Support libraries rewriting using a webpack manigest.json » Support libraries rewriting using a webpack manifest.json
Version: 8.9.x-dev » 9.2.x-dev
Pasqualle’s picture

nod_’s picture

Issue tags: +JavaScript

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

yoerioptr’s picture

I 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 defined manifest.json and looks something like this.

<?php
function my_theme_library_info_alter(array &$libraries, string $extension): void {
  /** @var \Drupal\Core\Extension\ThemeExtensionList $theme_extension_list */
  $theme_extension_list = \Drupal::service('extension.list.theme');
  $module_path = realpath($theme_extension_list->getPath('my_theme'));

  foreach ($libraries as $name => $library) {
    if (isset($library['js'])) {
      foreach ($library['js'] as $asset_source => $options) {
        if (isset($options['manifest'])) {
          $manifest = json_decode(file_get_contents("$module_path/{$options['manifest']}"), TRUE);
          $asset_destination = trim($manifest[$asset_source] ?? '', '/');
          if (!empty($asset_destination)) {
            unset($options['manifest']);
            unset($libraries[$name]['js'][$asset_source]);
            $libraries[$name]['js'][$asset_destination] = $options;
          }
        }
      }
    }

    if (isset($library['css']['theme'])) {
      foreach ($library['css']['theme'] as $asset_source => $options) {
        if (isset($options['manifest'])) {
          $manifest = json_decode(file_get_contents("$module_path/{$options['manifest']}"), TRUE);
          $asset_destination = trim($manifest[$asset_source] ?? '', '/');
          if (!empty($asset_destination)) {
            unset($options['manifest']);
            unset($libraries[$name]['css']['theme'][$asset_source]);
            $libraries[$name]['css']['theme'][$asset_destination] = $options;
          }
        }
      }
    }
  }
}
?>

This allows you to define a manifest.json path which will be used when the caches get rebuilt. The libraries.yml looks something like this.

main:
  js:
    build/js/main.js: { manifest: 'build/manifest.json' }
  css:
    theme:
      build/css/main.css: { manifest: 'build/manifest.json' }
  dependencies:
    - core/jquery
    - core/drupal

admin-tools:
  js:
    build/js/admin-tools.js: { manifest: 'build/manifest.json' }
  css:
    theme:
      build/css/admin-tools.css: { manifest: 'build/manifest.json' }

Here is an example manifest.json

{
  "build/js/main.js": "/build/js/main.js",
  "build/js/admin-tools.js": "/build/js/admin-tools.js",
  "build/css/main.css": "/build/css/main.css",
  "build/css/admin-tools.css": "/build/css/admin-tools.css"
}

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.