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:
- The different update processes currently in existence.
- The side-effects of each of these update processes.
- Inspecting Composer and NPM’s updatability. (This blogpost)
- Updating Compony components.
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.org)
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 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
Splitting up concerns #
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.