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.
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.
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.
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.
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):
- Colour contrast
- Heading hierarchy and page structure
- Providing alternative text for images and link text on icons
- Ensuring hidden content is accessible and doesn't create keyboard traps
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.
- Baseline styles for consistent colour and typography.
- A selection of simple element and form styling.
- A best-practice grid system and layout helper classes.
- Some more complex design components to demonstrate how elements can be combined.
- Full page mockups showing how layouts and components can be combined.
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.
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.
Do you still support IE? If not why is transpiling needed?