I copied the Bartik theme files as the base for a new theme and switched “base theme” in theme.info.yaml to “stable”. I also did a find and replace for “bartik” and changed it to my theme’s name. The theme.libraries.yaml file has sections for base, layout, component, and theme in the css section. This organization scheme seems to be arbitrary, since I was able to remove these sections and put them all in the same section. However, it looks like the key names must either match a folder or file in the css folder.

Since I would like to use scss instead of css, I think I will setup a single css file in the library file, which will be the compiled scss, e.g.

global-styling:
version: VERSION
css:
global:
css/global.css: {}

I moved the existing Bartik css files into /scss/default and renamed them to to have the scss extension. Then I @imported them into global.scss. From the theme’s root, I ran scss scss/global.scss:css/global.css to compile. Afterwords, I had a global.css and global.css.map in the css folder. After clearing the cache, my theme’s styles worked with the compiled css, and scss source maps were working.

Running scss --watch scss/global.scss:css/global.css I had a nice scss-only workflow for the global styles.

I’ve had to the clear the drupal cache several times as I’ve been working, so as I’m developing I just keep this page open /admin/config/development/performance. There is a tool called drush which can clear the cache from the command line, however, it looks like it required some initialization. Since I created my project before I knew about drush, I wasn’t able to get it to work. As a side note, I installed composer inside my server’s docker container and tried to install drush from there. Composer just hung when I tried to install drush, and then I realized that the container was running out of memory. If you’re going to use composer in a Docker container, you’ll have to increase the memory limit of the container.

The theme.breakpoints.yml file doesn’t actually handle css breakpoints. It’s just there so you can tell Drupal what your breakpoints are if some Drupal module needs to know that.

After adding a new template file, you will need to clear the cache. You can edit existing template files and automatically see the changes (provided you’ve disabled the twig cache, see the links at the top).

When working with twig templates, you can get more information about a particular variable use {{ dump(variable) }}. To see all available variables use {{ dump(_context|keys) }}

To get the value of a non-referential field, you would do node.[field_id].value. See here.

To get the body content of a node use content.body.

You can filter values in Twig using pipe (|), e.g. with date you can format a date like {{ node.field_date_written.value|date("F jS, Y") }}. This will format Y-m-d as January 1st, 2010.

An entire page can have it’s own custom template. Content’s have a node id, e.g. “node/9”. You can create page--node--9.html.twig and copy the content from the default page.html.twig file. See Twig Template Naming Conventions.