VisualN Libraries Override
VisualN Libraries

This project is not covered by Drupal’s security advisory policy.

The module provides a basic plugin type used to register Drupal libraries. Simply, It returns libraries metadata in the same format as used in *.libraries.yml files. All such libraries are registered under visualn_libraries/ "namespace", i.e. machine names of registered libraries become "visualn_libraries/{library_name}". Generally a plugin needs to declare just one ::getLibrariesInfo() method. All registered visualn_libraries with js/css assets (and their presence status) are listed on VisualN Libraries UI submodule configuration page.

The idea is to develop a unified way of delivering and registering info about external libraries and their assets, that could be used across all Drupal projects. Such an approach resolves the issue when two independent projects use the same js/css assets package and thus need to have it registered as a library but know nothing about each other. This may typically lead to various conflicts, for instance, different versions of js assets loadded on the same page may break the site. Also it wouldn't allow to reuse libraries registered in one module by another one in a common manner.

Another goal is to provide a UI to override registered libraries. It allows to avoid conflicts for the case described above by making one of the modules to use another modules library files instead of its own. It is done by substituting library dependencies in a generic manner and thus fully fits in with Drupal development approaches. The functionality is provided by VisualN Libraries Override submodule.

For a plugin example see VisualN Libraries Example submodule.

For composer driven libraries management, the module registers a php namespace for /components/visualn_libraries/src/Plugin/VisualN/Library path, e.g.:

namespace visualn_libraries\Plugin\VisualN\Library\colorbox;

Workflow without composer

For users that don't use composer to manage dependencies the module has some additional options. It expects every other project that depends on visualn_libraries/ libraries to declare them in a my_module.visualn_libraries.yml file in a simple format*:

library_name:
- version: 1.0

Those dependencies get listed on VisualN Libraries list page as well. If library details couldn't be found, then "No data provided" text appears near it.
In future a simple web service can be implemented to fetch that data (list of files to register, library dependencies etc.) right from the UI and manually unarchive files to required locations.

* The format of the file is for reference, may later be changed

The objectives of the module

  • Portability between environments (e.g. dev and prod), in-code dependencies
  • Avoid and resolve potential conflicts between libraries and their versions
  • Provide a common namespace for all libraries
  • Automate fetching required libraries into project structure
  • Reusability of libraries across Drupal sites
Supporting organizations: 
Development and maintenance

Project information

Releases