What problem are we trying to solve?

I had been asked to improve the layout of an existing and actively evolving project. The site had got itself into a knot of of inline styles, plus a ramble set of CSS files. So my first job was to simplify the status quo.

My development site is a clone of the live site, in a parallel directory on the same server. I can login by SSH, and yes, I could use a text editor on the server as a flex. But what I really need is a fully-fledged code editor app (VS Code), plus PostCSS to help make my resulting CSS highly reliable and compact.

This appears contradictory: I want to work remotely and locally. So we’re going to start by resolving that with something called SSHFS (Secure Shell Filesystem).

This is aimed at developers — front- or backend — who need to manage the styling of a relatively sophisticated, probably bespoke, website, and are looking to advance their frontend skills. In other words, you’ve got a lot of styles — probably in multiple files — to write and organise. You might find this useful if you’re creating or improving a WordPress or Drupal theme, or if you’re trying to create a layout with cutting edge styles and browser support is a very real concern. If you’re a relatively new to Web development, you’ll need to be conscious of some industry standard concepts (see above).

This is a deliberately super-lean setup. PostCSS is often used as a process within a bigger build-tool like Webpack, but in this case that would simply add unnecessary complexity for no extra value. In fact, what I’d like to demonstrate is that PostCSS is actually very effective in it’s own right.

What is SSHFS?

This is a method for securely connecting a directory in a remote server’s file system directly to a designated folder on your own computer. The net result is that, when you open or save a file, you’re actually interacting with a server, but you can also use all your preferred apps on your own machine, as if the file was a local one. (This is essentially how Dropbox and Google Drive work.)

SSHFS is an advancement on SSH, so you will already need to have public-private keys already setup, and be able to login and navigate around via SSH. I installed macFuse as my SSHFS package, but there are Linux and Windows alternatives.

This is my local file tree model, where /dist is the server’s mount point, and /src is my local working directory:

MyProject 
  — dist
   — css
     style.css
  — src
    main.css

Hooking up with SSHFS

All of this is to circumvent having to install Node.js on the remote server (which would be just be clutter going forward). What’s going to happen here is that the /dist directory is going to be “mounted” by the remote file system via SSHFS. I’m going to be doing my development work in the /src directory, and PostCSS will be setup to drop a single, minified CSS file into the /dist/css/ directory.

In your .ssh/config file add an entry that follows this pattern:

Host myproject
  Compression yes
  Hostname my.project.hostname
  User username
  IdentityFile ~/.ssh/id_rsa

With these two things setup, this single command should mount the remote server onto your own designated folder (obviously you’ll:

sshfs myproject:/path/to/dev/site/ /local/mount/point/dist

PostCSS

Navigate to your project directory and — assuming you have Node installed and have used NPM before — start a new project.

npm init

This isn’t a post about the pros and cons of any given array of PostCSS plugins, so treat this as a starting suggestion. (Note that I haven’t used the -D flag here, because there isn’t really a development environment in this case: you should do whatever makes sense for your project).

npm install postcss postcss-cli cssnano postcss-preset-env postcss-import

You will need to manually create a postcss.config.js file and save it at the project root (i.e. at the same level as package.json). Note that PostCSS Preset Env has configuration options:

module.exports = {
  plugins: [
    require('postcss-import'),
    require('postcss-preset-env')({
      stage: 2
    }),
    require('cssnano') 
  ]
}

Check that your package.json file is listing the dependencies installed in the previous step. Again, you’ll need customise the script to suit your own workflow, but to run PostCSS I used:

"scripts": {
    "postcss:watch": "postcss src/main.css -o dist/css/style.css -w"
}

Executed with npm run postcss:watch which will pick up that main.css file, run the PostCSS plugins over it, then save it as style.css in the parallel directory. The script has was a watch flag -w set, which means it will run every time changes are detected on main.css.

The net result is that I can:

• “Write the CSS of the future today” and be confident it’s supported by the all the browsers I need it to be.
• I can order my working CSS files however it makes sense to me, and output all that to just one, minified file.
• It will have any required vendor prefixes automatically added to the affected selectors.

These are the three tutorials I used to get started with PostCSS, in the order I found them most useful. I haven’t followed their direction exactly (notably I didn’t install the NPM packages as dev dependencies because that’s a redundant step for my circumstances), although you might want to if you’re new to NPM.