PreviousNext: Overview of our Front-end Stack

Front-end technology stacks tend to move quickly. At PreviousNext, we have been constantly evolving the tech stack to take advantage of best-practice.

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.

by
kim.pepper
/

Our front-end stack consists of the following tools:

  • npm, manages all our dependencies and runs our build scripts.
  • post-css to modernise our CSS.
  • kss-node builds the styleguide.
  • stylelint and eslint lints our CSS and JS.
  • Browsersync is used for testing and CSS live reloading.
  • babel and rollup.js are used to transpile and bundle ES6 js.

NPM

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

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.

Browsersync

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.

Maintaining coding standards

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

SMACSS, BEM and DRY

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

CSS Structure and Categorisation

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/*

Testing for accessibility

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):

Mixtape

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:

JavaScript ESM

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. See Using ES6 in your Drupal Components.

Summary

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.


Go to Source
Author: