
Kim PepperCo-Founder & Tech Director
Front-end technology stacks tend to move quickly. At PreviousNext, we are constantly evolving the tech stack to take advantage of best practices.
In this post, we take a closer look at the front-end tools we use at PreviousNext in 2021 and some of the rationale behind the decisions.
Our front-end stack consists of the following tools:
Modern front-end development leverages many open-source libraries for JavaScript. To manage all this, we use npm as the package manager. There was a period where frustrations with performance led to us switching to yarn, but these issues have been resolved in more recent versions of npm, so we switched back.
We also store a number of script aliases in package.json to simplify the day to day task. This includes compiling CSS/JS and generating a styleguide. For example:
$ npm start
will automatically watch for any changes to .css or .js files, will build the CSS, styleguide, and live reload Browsersync.
KSS Node is a Node.js implementation of Knyle Style Sheets (KSS), "a documentation syntax for CSS" that's intended to have syntax readable by humans and machines. We use KSS to generate our living styleguides.
We use Browsersync to speed up the feedback loop. Changes to CSS and JS are compiled and automatically sync'd with the browser, so you see changes immediately.
By default Linting is required for all custom CSS and JS files. This makes code reviews way easier, as we're not having to pick up on style changes, and can focus on the meaningful changes.
We use Stylelint for CSS linting, and ESLint for JavaScript linting with
We follow the SMACSS approach to categorisation, breaking CSS down into modular components.
We also follow the basic BEM naming pattern.
When combined with DRY (donβt repeat yourself) approach to CSS in general, this ensures the Drupal theme meets current coding standards.
We use some alternative terminology as these are used in Drupal already (e.g. blocks and modules). They map to the original as follows:
# From SMACSS
module = component
submodule = variant
theme = variant
# From BEM
block = component
modifier = variant
We like to compile CSS files into separate components:
# Custom variables; included in all other files.
/src/_constants.css
# Base styles; resets, element defaults, fonts, etc.
/src/base/*
# Layouts and grid systems.
/src/layout/*
# Form fields.
/src/form/*
# Components; independently styled components that can live anywhere in a layout.
/src/*
We regularly run our Drupal theme through Nightwatch Axe to make sure we aren't creating any accessibility errors.
This will review the following (and more):
On top of all this, PreviousNext has developed it's own design system, Mixtape. This allows us to re-use common design components across the sites we develop.
Mixtape provides:
Our JavaScript builds have evolved to leverage ES6 modules/imports and code splitting with Rollup.
Entry points from custom profiles, modules, and themes are consumed and outputted with common chunks into site wide libraries. You can read more about our approach in our post on Performance improvements with Drupal 8 Libraries.
All JavaScript uses ES6 syntax, which is transpiled using Babel. This allows us to develop using modern JavaScript while still supporting older browsers. SeeUsing ES6 in your Drupal Components.
Front-end development is constantly evolving, but as you can see, we can keep the front-end development of Drupal sites up to date using the latest tools and techniques.