Asset Packagist as State of the Art in 3rd part library integration

The introduction of Composer in Drupal 8 was a great improvement over managing packages via Drush Make, but however did leave some questions about properly load 3rd party Javascirpt libraries - here's an advice how you should do it.

Almost exactly 3 years ago, I wrote an article about 3rd party library integration in Drupal 8. But this however was about half a year before Drupal 8.0 was finally released an almost exaclty one year before Drupal 8.1 was released as first fully Composer comptiable version. So, a lot of things have changed since then. I already voted for a Composer based solution and proposed a way to do it in one of my contrib projects. But that approach is now fully obsolete at all.

One solution, I've done for a long time now, is to define a repository (within the "repositories" section of a composer.json file) pointing to the Github URL of a Javascript library and define it as type "drupal-library" and use composer/installers package to install it into web/libraries directory. This approach however never really fully satisfied me, as well as many others. There's also an open issue about that: Drupal core should help make 3rd party library management not torturous. Today, Moshe Weitzman replied with a great comment there, mentioning that the most important Drupal distros and starter kits use Asset Packagist at the moment to solve this problem - these projects are Thunder, Lightning and the Commerce 2.x project template.

Follow the Lightning link in the last paragraph to get a very good tutorial about the needed steps. In short, you need to load the oomphinc/composer-installers-extender package, add "installer-types" and "installer-path" sections to your composer.json and are now able to load any library that is registered to NPM or Bower just as you can do with any Drupal module or PHP library that is registered on Packagist.

The only problems I've encountered so far have nothing to do with Asset Packagist itself, but just to the unfortunate fact that many JS libraries in the wild do not have a consistent naming. The first two packages I've tried, both lead me to similar problems: take the rateit.js library for example. On Github, the project is named "gjunge/rateit.js", while it is registered in NPM and Bower both as "jquery.rateit". That means, when you load define the Github project as repository in your composer.json and then load it, you'll end up having a directory named "libraries/rateit.js". But if you use Asset Packagist, no matter if you chosse to load it from NPM or Bower, it will be loaded into "libraries/jquery.rateit" instead. And that's the problem.. because anywhere there's a Drupal module, defining a libraries.yml file, and there you'll need to know the path of the JS and CSS assets you want to use. Similar problem exists with PhotoSwipe libary, where it is hosted on Github with the two uppercase letters, but registered fully lowercase on NPM and Bower. There's even an Issues with Composer Install issue on the PhotoSwipe Drupal module page, where I originally strongly voted to let the module expect the files in "libraries/PhotoSwipe" directory instead of "libraries/photoswipe", in order to allow Composer installs at all. But now, having tried Asset Packagist, I totally favour using that package. Coincidentally that would mean for the PhotoSwipe module that this shouldn't be changed at all - good luck that the maintainer hasn't responded for a longer time already ;) :)