During my work on the D8 port of our Outdated Browser module, I’ve got in touch with several API changes of Drupal 8. One of them I want to describe now is the integration of third party Javascript libraries.
How it used to be in D7
Before I begin, here is short summary about, how this is done in Drupal 7. Basically there is hook_library() in core API, but this has some disadvantages. But thankfully we have the great Library API module, which became the unofficial standard way to integrate JS and/or CSS assets, as every module I know relies on Libraries API to integrate their external libraries – so did we with our module. Libraries API offers huge advantages over the core API method, whereas the most important one is the introduction of a central file directory – sites/all/libraries – where all the external assets should land. This does not only make the file structure of your site cleaner, but also helps massively in updating both modules and libraries. Additionally, there are many extra benefits like having possibility to control availability and correct installation of the assets during runtime easily.
Core API changes in Drupal 8
The drupal_add_js() and drupal_add_css() functions for manual inclusions of JS/CSS files have been removed in favour of library definitions that properly declare their dependencies. As a result of this, all modules and also themes have to declare their libraries in order to include JS and/or CSS files. During the development of D8 the way of declaring a library evolved from a renamed info hook (hook_library_info()) to finally using YAML (like in many other places in D8) by describing the libraries in *.libraries.yml files. The info hook finally was removed fully. See the change record for more information. The new hook_library_info_alter() hook is of course still there.
Another big change is the usage of Composer for dependency management, like many other modern frameworks do. Although Composer is primarily for PHP libraries, it can be used for JS libraries too. Using Composer not only spares you manually downloading the library from Github, etc and afterwards manually extracting and uploading the files to your server, but also eliminates the error source of placing the files into the right directory structure. (Note: Composer integration is not fully finished yet, see: https://www.drupal.org/node/2372815)
Libraries API and Drupal 8
At the time of writing the Libraries API module is unfortunately completely broken in D8 (since beta5). I was looking around, how other modules depending on Libraries API are handling this problem at the moment. I doubt that any of these are working correctly at the moment because the libraries_load() function is still called, even though it’s not working at all.
Another aspect I’m not very happy about is that currently (I’m sure/hoping that this will be changed in future) you’d still have to implement an info hook in order to declare your libraries with Libraries API, which is not only a breach of style in comparison to the *.libraries.yml file mentioned above. It also adds some unwanted fragmentation to your module: on the one hand, you would have to declare the third party assets via the Libraries API info hook, on the other hand you would still have to write the libraries.yml file and declare your additional assets, which is at least the JS file containing the initialization call.
These two problems led me to the decision to – at least temporarily – drop Libraries API support completely in the D8 version of Outdated Browser.
Do we still need Libraries API in D8 at all?
I would say at least “not as much as before”. I’m sure it will still have its place once the necessary changes are done. The core API has become more powerful in this area, so you can find an easy way to work without it. But on the side there are still some things I’m missing. I would prefer a central repository for all external assets, for the same reasons as in the past. But even this is planned for core anyway, as important part of the full Composer integration. And this will likely also affect Libraries API again. If I have to make a prediction about the future of Libraries API, I would say that I believe, it will have a similar evolution either like e.g. Token. Although (big parts of) its functionality became part of Drupal core, Token still exists, as there are still some extra benefits added by the module, which may be merged fully into core in a future version. And yes, of course I can imagine to re-include Libraries API support (or even module dependency, if it makes sense) once it’s working again.
What do you think about this topic? Do you have already experience in integrating external libraries in D8? How did you / how do you plan to handle this? What caveats did arise?.... Tell us, feedback is always welcome! You may also want to have a look on Outdated Browser module's source code.
- Antworten