Inspecting Composer and NPM's updatability

If we talk about Drupal theming, then we mostly get in contact with 2 package managers: Composer and NPM. This blogpost provides both an explication and a deep dive in to how they got build conceptually, so that we can learn from them.

This blogpost is the third in a mini-series where we explore the different facets of updatability:

  1. The different update processes currently in existence.
  2. The side-effects of each of these update processes
  3. Inspecting Composer and NPM’s updatability. (This blogpost)
  4. Updating Compony components.

Composer #

Composer currently utilises the “Schrodinger’s update” process, while also allowing for tools to automate it in a way that it becomes a "suggestive update” process.

There are many benefits to using Composer. In short, it allows us to systematically manage a sprawling list of dependencies (and their subsidiary dependencies). It assists with locating, downloading, validating, and loading said packages, all while ensuring that exactly the right versions for each package are used. (ref:

Drupal relies on Composer for dependencies, Drupal core, and contrib modules. That's why you now have to write a Composer command in order to install or update a contributed module.

Composer is a perfect match for Drupal. it downloads Drupal core, the contrib modules and all of it's dependencies. But it also comes with a very strong side-warning: don't edit anything you download through Composer.

You wouldn't edit files in the Drupal Core folder in the same way that you would also not change something in the source code of a contrib module.

So that means that whatever we download through a tool as Composer, we shouldn't edit. Not only should we not edit it, we should also not commit it to Git! The only thing that you would commit coming from Composer is the composer.lock file. This is a lock file so Composer knows which packages to download when it is run again.

Not touching the code you download with Composer, doesn’t mean that you can’t interact with it through code however! We are still able to change Drupal’s behaviour, by using hooks and configuration. Hooks are the way how customly written code can interact with the downloaded code by Composer.


NPM is also a package manager. It’s a tool that automates the process of installing, upgrading, configuring, and removing JavaScript packages. It does this in a "Schrodinger’s update" way, but it has a history of being more of a migration than an update.

As a developer, we can download from a big range of JavaScript solutions made by others and not worry about dependencies.

NPM has a lot of similarities with Composer: anything you download with NPM becomes untouchable code. And while Composer users a composer.lock file, the NPM equivalent is a package-json.lock file.

In JavaScript you have to import packages in your custom code. One of the most common ways is to write 

import "module-name”;

And while Drupal uses hooks, in JavaScript land, you can pass along variables to certain function names to the packages that you have imported.

Splitting up concerns #

What both systems have in common is that they separate off custom code and code that you didn’t write yourself (3rd party). This 3rd party code, would be Drupal Core, Contrib modules or other Composer packages such as vendors. In JavaScript, we have that separated off in a node_modules folder. Both systems come with a convention on how you should interact with untouchable 3rd party code.

Both package managers provide a lock file where we can lock a version of a certain piece in to place. 

Published 09 December 2019
Updated 10 January 2020