Libraries can also be overridden to modify assets declared by other libraries, possibly added by a base theme, by a module, or even the Drupal core. The ability to override libraries includes removing as well as replacing assets altogether. The same way we reference a library from our *.info.yml file, we can override libraries by adding the following:

libraries-override:
  # Replace an entire library.
  core/drupal.vertical-tabs: example/vertical-tabs
  
  # Replace an asset with another.
  core/drupal.vertical-tabs:
    css:
      component:
      misc/vertical-tabs.css: css/vertical-tabs.css
  
  # Remove an asset.
  core/drupal.vertical-tabs:
    css:
      component:
      misc/vertical-tabs.css: false
  
  # Remove an entire library.
  core/modernizr: false

In this case, the libraries-override configuration achieves something different for each line. Whether it is replacing an entire library or removing an asset, we now have the flexibility to control assets like never before.

Libraries can also be extended to allow overriding CSS added by another library without modifying the original files. This can be done by adding the following to our *.info.yml configuration as follows:

libraries-extend:
  core/drupal.vertical-tabs: 
    - example/tabs

In this case, the libraries-extend configuration is extending Drupal's own core.libraries.yml file and extending the drupal.vertical-tabs library with additional styling.

While we now have a general understanding of how libraries are defined, overridden, and extended, we have only dealt with libraries globally loaded into our Drupal instance using our configuration file. However, there are two more methods to include assets within a page directly, without the need to add it to every page.

While we will be learning all about Twig a little later in the chapter, we need to pause for a moment to reference a Twig function named {{ attach_library() }}. This function allows us to add to any Twig template a library that may include CSS or JS that will load on that page only.

For example, if we wanted to add the Slick Carousel (http://kenwheeler.github.io/slick/) to our page, we may define the library within our example.libraries.yml file as follows:

# Slick
slick:
  version: VERSION
  css:
    theme:
      vendor/slick/slick.css: {}
  js:
    vendor/slick/slick.min.js: {}
  dependencies:
    - core/jquery

We could then turn around and add the following to our Twig template:

{{ attach_library('example/slick') }}

This provides us with some nice functionality to define individual libraries for various user functions and also to have those assets used wherever we choose to attach them.

Another method to attach a library to an individual page depends on creating a *.theme file, which allows us to use preprocess functions to manipulate page variables. We will learn a lot more about creating a *.theme file a little later in the chapter, but it's important to note that we could attach the same Slick Carousel to our homepage without globally calling it by using a preprocess function, as shown in the following example:

function example_preprocess_page(&$variables) {
  if ($variables['is_front']) {
    $variables['#attached']['library'][] = 'example/slick';
  }
}

Here, we are checking to see whether we are on the homepage of our website and attaching our Slick library using the #attached library array. Again, this may seem a little bit advanced at this point but does merit mentioning.

The last section we will want to cover when working with any *.info.yml file is about regions that can be defined for the layout of our theme.