Nowadays, the team recommends using production-grade React frameworks like NextJS, Remix, Gatsby, or Expo for native apps. While frameworks are the preferred choice, the React team also recommend using Vite or Parcel for custom build processes.

This is partly because the CRA package has not been updated for about a year. This may cause some problems where packages already updated to more recent versions cannot be used within an existing application. As a result, you may need to update existing applications by replacing the CRA package with the recommended alternatives — Vite or Parcel.

This article walks you through the steps for migrating a production-based application from CRA to Vite. You will learn the "why" of each step, how to retain Jest for tests, and how to update your browserslist since it doesn't work with vite out of the box.

In the conclusion section, you can find a sample pull request that includes all the changes. At the end of each step, you will find a sample commit text which shows the code change required per step.

Step 1: Install Vite and Plugins

Here are the commands to install the packages we need:

yarn add vite @vitejs/plugin-react vite-tsconfig-paths

OR

npm install vite @vitejs/plugin-react vite-tsconfig-paths

Apart from Vite, we are adding two plugins — @vitejs/plugin-react and  vite-tsconfig-paths.

The vitejs/plugin-react plugin enables fast refresh in development, uses automatic JSX runtime, and custom Babel plugins or presets. It enriches your React development experience.

The vite-tsconfig-paths plugin resolves imports for TypeScript's path mapping. For example, you can use components/ComponentName instead of ./../components/ComponentName.

Other Vite plugins

Another plugin you could consider is vite-plugin-svgr, which transforms SVG into React components and uses svgr under the hood. I left it out since we do not have such a use case in the application I’m migrating.

You can also checkout other official Vite plugins here.

Step 1 sample commit.

Step 2: Create a Vite config file

On running vite in the command terminal, Vite tries to find a vite.config.ts file inside the project's root directory. You can read more on Vite's page for how to further configure this file for intellisense, environment based configurations, async configuration, and env variables usage.

At your application’s root, create a file named vite.config.ts with the following content:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import viteTsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
    // depending on your application, base can also be "/"
    base: '',
    plugins: [react(), viteTsconfigPaths()],
    server: {    
        // this ensures that the browser opens upon server start
        open: true,
        // this sets a default port to 3000  
        port: 3000, 
    },
})

Step 2 sample commit.

Step 3: Create a Vite Types File Reference

This step is needed to reference a type declarations file which aids type checks and Intellisense. By default, Vite types are for a NodeJS environment. For client side code, Vite provides the type definitions in vite/client.d.ts.

At your application’s root, create a file named vite-env.d.ts with the following content:

/// <reference types="vite/client" />

Step 3 sample commit.

Step 4: Move the index.html File

Vite has a root directory which your files are served from. Since index.html is the entry point for Vite's server, the file needs to be in the root directory.

From the public directory, move the index.html file to the root of your project.

Step 4 sample commit.

Step 5: Update the index.html File

Two updates are necessary here:

Remove %PUBLIC_URL%

Vite automatically resolves URLs inside index.html, so there's no need for %PUBLIC_URL% placeholders. You can do a search and replace inside your index.html file for this. Be sure to remove all occurrences.

Before:

<link rel="icon" type="image/svg+xml" href="%PUBLIC_URL%/favicon.svg" />

After:

<link rel="icon" type="image/svg+xml" href="/favicon.svg" />

Add module script to the bottom of the body tag

Vite treats index.html as source code and part of the module graph. It resolves <script type="module" src="..."> that references your JavaScript source code.

At the bottom of the body tag in index.html file, add the script as shown below:

<body>
    {/* others here */}
    <script type="module" src="/src/index.tsx"></script>
</body>

Step 5 sample commit.

Step 6: Replace CRA with Vite

You can now remove CRA, add Vite scripts to the package.json file, and update tsconfig.json.

Remove CRA

To remove CRA, run the following command. This will remove react-scripts from our installed packages.

yarn remove react-scripts

OR

npm uninstall react-scripts

After running the command above, delete the react-app-env.d.ts file.

Add Vite scripts to the package.json file

With Vite installed, you can use the vite binary in your scripts. This could mean replacing react-scripts in a few places. Your focus should be on the start and build keys. The preview key is an addition which helps to preview production build locally.

Note that start is vite and not vite start.

{  
  "scripts": {
    "start": "vite", // start dev server
    "build": "tsc && vite build", // build for production
    "preview": "vite preview" // locally preview production build
  }
},

Update tsconfig.json

Here, your focus should be on the isolatedModules, lib, target, and types. For more options, here is a sample tsconfig file from Vite.

{  
    "compilerOptions": {    
        "lib": ["dom", "dom.iterable", "esnext"],    
        "target": "ESNext",    
        "types": ["vite/client"],
        "isolatedModules": true,
    },
 }

Update process.env.REACT_APP_VARIABLE (optional)

This is necessary if your application uses environment variable. Vite uses import.meta.env.REACT_APP_VARIABLE instead of process.env.REACT_APP_VARIABLE. You can find more details on Vite's env variables and modes here.

Before:

process.env.REACT_APP_VARIABLE

After:

import.meta.env.REACT_APP_VARIABLE

Replace REACT_ with VITE_ (optional)

You only need this if you updated process.env above. Replace your REACT_ environment variables to start with VITE_. This is needed because Vite filters out any env variable not starting with VITE_.

Before:

REACT_APP_API_BASE

After:

VITE_APP_API_BASE

Step 6 sample commit.

Step 7: Run your Application

yarn start

OR

npm start

Congratulations! You have successfully completed the first step in migrating your application from CRA to Vite. You should see a screen that looks like the image below:

No sample commit. ;)

Possible blockers and their solutions

global is not defined error

If you have this error, define global inside your vite.config.ts file as shown below:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  // ...
  define: {
    // here is the main update
    global: 'globalThis',
  },
});

If you use @emotion/react or @emotion/css

You need to inform Vite about this. To do this, install @emotion/babel-plugin.

yarn add @emotion/babel-plugin

OR

npm install @emotion/babel-plugin

Then update your Vite's react plugin in the vite.config.ts as shown below:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import viteTsconfigPaths from 'vite-tsconfig-paths';
import svgr from 'vite-plugin-svgr';

export default defineConfig({
  // ...
  plugins: [
    // here is the main update
    react({
      jsxImportSource: '@emotion/react',
      babel: {
        plugins: ['@emotion/babel-plugin'],
      },
    }),
  ],
  // ...
});

Oh no, my unit tests are not working!

At this point, try running your unit tests — yarn test or npm run test. It’s possible that they don’t work. The following steps highlight how you can fix your unit tests.

Your unit tests are not working because CRA uses react-scripts test to run tests, so we want to switch to using jest.

Step 8: Install Jest and TypeScript-related Dependencies

To start with, you need to install jest, ts-jest, and jest-environment-jsdom. jest will be our new binary for running the tests, [ts-jest](https://www.npmjs.com/package/ts-jest) is a transformer with source map support which allows you to run tests in TypeScript projects, and jest-environment-jsdom imitates the browser's behavior during test runs.

yarn add -D jest @types/jest ts-jest jest-environment-jsdom

OR

npm install --save-dev jest @types/jest ts-jest jest-environment-jsdom

Step 8 sample commit.

Step 9: Update Jest Config

This depends on your current Jest configuration. If it is configured inside package.json, you can update as follows. Here, you focus on preset, testEnvironment, moduleNameMapper, and modulePaths.

preset is set to ts-jest/presets/js-with-ts to allow TypeScript with JavaScript. You can also just set it to ts-jest depending on your application.

moduleNameMapper configures Jest to gracefully handle assets such as stylesheets and images.

  "jest": {
    "preset": "ts-jest/presets/js-with-ts",
    "testEnvironment": "jest-environment-jsdom",
    "moduleNameMapper": {
      "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
      "\\.(css|less)$": "<rootDir>/__mocks__/styleMock.js"
    },
    "modulePaths": [
      // you can update this to match your application setup
      "<rootDir>/src"
    ],
  },

Since we referenced a file in moduleNameMapper above, we need to create the file and it's corresponding files. Step 10 takes care of this. This setup is explained further in Jest's documentation here.

Step 9 sample commit.

Step 10: Add the __mocks__ Directory to the Root of Your Project

At the root of your project, create a folder named __mocks__.

Inside the created __mocks__ folder, add a file named styleMock.js and add the following content:

module.exports = {}

Inside the created __mocks__ folder, add a file named fileMock.js and add the following content.

module.exports = 'test-file-stub'

Step 10 sample commit.

Step 11: Update the package.json Scripts

Now that we have jest properly installed, we can replace react-scripts tests with jest. Changes should be as shown below. If you do not have the test:coverage or test:debug keys in your code before, feel free to ignore.

Before:

"scripts": {
    "test": "react-scripts test",
    "test:coverage": "react-scripts test --coverage .",
    "test:debug": "react-scripts test --inspect-brk --runInBand --no-cache"
}

After:

"scripts": {
    "test": "jest",
    // you can add this to keep watch mode on
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage .",
    "test:debug": "jest --inspect-brk --runInBand --no-cache"
}

Step 11 sample commit.

Step 12: Run your Tests

yarn test

OR

npm test

If you face a problem related to import.meta, you can resolve this by moving all your environment keys to a single file and mocking this file in your test. You can take a look at this commit to have a better understanding of what I mean.

No sample commit. :)

Ah, it works! But how about the browserslist config?

What is browserslist config?

This is a configuration used to share your target or supported browsers among multiple frontend repositories.

There are various standards depending on the industry. For example, in EdTech, it's possible that all users learning online use similar browsers in terms of brand, version, and screen size. This list of the commonly used browsers can easily become a standard for the EdTech industry.

A sample application of the browserslist config is when you need to be compatible with older browsers. Passing this range to the browserslist config helps your bundler to compile your code using polyfills that are compatible with your target browsers. This way, your page has optimized performance with good user experience.

Mozilla defines a Polyfill as a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it.

Browserslist config is often set in the package.json or .browserslistrc file as shown below.

package.json

{
  "browserslist": [
    "iOS >= 9",
    "Android >= 4.4",
    "last 2 versions",
    "> 0.2%",
    "not dead"
  ]
}

.browserslistrc

iOS >= 9
Android >= 4.4
last 2 versions
> 0.2%
not dead

You can also read more about Browserslist here.

Why is browserslist a Problem with Vite?

Vite uses ESBuild under the hood which expects a different format to the usual browserslist format.

ESBuild expected format: ['es2015', 'safari11', 'ios11']

Browserslist format: ['defaults', 'Safari >= 11', 'ios_saf >= 11']

As a result of this discrepancy, Vite ignores your browserslist configuration which is currently in the package.json or .brwserslistrc file.

To fix this, you can use a package called browserslist-to-esbuild which does this conversion under the hood and pass the config to build.target inside the vite.config.ts file. Steps 13 and 14 take care of this.

Step 13: Install browserslist-to-esbuild

yarn add browserslist-to-esbuild

OR 

npm install browserslist-to-esbuild

Step 13 sample commit.

Step 14: Confiure the browserslist in Vite Config

In the vite.config.ts file, update as shown below.

import { defineConfig } from 'vite'
import browserslistToEsbuild from 'browserslist-to-esbuild'

export default defineConfig({
  ..
  build: {
    // --> ["chrome79", "edge92", "firefox91", "safari13.1"]
    target: browserslistToEsbuild(), 
  },
  ..
})

And then, you can pass your configs as shown below,

export default defineConfig({
  ..
  build: {
    // you can also pass your usual browserslist config here
    target: browserslistToEsbuild([
        '>0.2%',
        'not dead',
        'not op_mini all'
    ]),
  },
  ..
})

Step 14 sample commit.

Conclusion

Voilà! You're done and your application is fully migrated.

Missing any step? Here is a sample pull request that highlights all the changes involved.

You have learned the "why" and "how" of replacing create-react-app with Vite. I hope you are as proud of yourself as I was of myself for what I have learned in the process of the migration.

Alrighty, that it! Happy coding!

Why uniqueness validation is not enough

Even with the uniqueness validation, unwanted data sometimes gets saved in the database. For clarity, let’s take a look at a user model shown below:

class User
    validates :username, presence: true, uniqueness: true
end

To validate the username column, rails queries the database using SELECT to see if the username already exists. If it does, it prints “Username already exists”. If it doesn’t, it runs an INSERT query to persist the new username in the database.

When two users are running the same process at the same time, the database can sometimes save the data regardless of the validation constraint and that is where the database constraints (unique index) comes in.

If user A and user B are both trying to persist the same username into the database at the same time, rails runs the SELECT query, if the username already exists, it informs both users. However, if the username doesn’t exist in the database, it runs the INSERT query for both users simultaneously as shown in the image below.

Now that you know why the database unique index (database constraint) is important, let’s get into how to set it. It’s quite easy to set database unique index(es) for any column or set of columns in rails. However, some database constraint in rails can be tricky.

A quick look at setting a unique index for one or more column

This is quite as simple as running a migration. Let’s assume we have a users table with column username and we want to ensure that each user has a unique username. You simply create a migration and input the following code:

add_index :users, :username, unique: true

Then you run the migration and that’s it. The database now ensures that no similar usernames are saved in the table.

For multiple associated columns, let’s assume we have a requests table with columns sender_id and receiver_id. Similarly, you simply create a migration and input the following code:

add_index :requests, [:sender_id, :receiver_id], unique: true

And that’s it? Uh oh, not so fast.

The problem with the multiple column migration above

The problem is that the ids, in this case, are interchangeable. This means that if you have a sender_id of 1 and receiver_id of 2, the request table can still save a sender_id of 2 and receiver_id of 1, even though they already have a pending request.

This problem often happens in a self-referential association. This means both the sender and receiver are users and sender_id or receiver_id is referenced from the user_id. A user with user_id(sender_id) of 1 sends a request to a user with user_id(receiver_id) of 2.

If the receiver sends another request again, and we allow it to save in the database, then we have two similar requests from the same two users(sender and receiver || receiver and sender) in the request table.

This is illustrated in the image below:

The common fix

This problem is often fixed with the pseudo-code below:

def force_record_conflict
    # 1. Return if there is an already existing request from the sender to receiver 
    # 2. If not then swap the sender and receiver
end

The problem with this solution is that the receiver_id and sender_id get swapped each time before saving to the database. Hence, the receiver_id column will have to save the sender_id and vice versa.

For example, if a user with sender_id of 1 sends a request to a user with receiver_id of 2, the request table will be as shown below:

This may not sound like an issue but it’s better if your columns are saving the exact data you want them to save. This has numerous advantages. For example, if you need to send a notification to the receiver through the receiver_id, then you’ll query the database for the exact id from the receiver_id column. This already became more confusing the moment you start switching the data saved in your request table.

The proper fix

This problem can be entirely resolved by talking to the database directly. In this case, I’ll explain using PostgreSQL. When running the migration, you must ensure that the unique constraint checks for both (1,2) and (2,1) in the request table before saving.

You can do that by running a migration with the code below:

class AddInterchangableUniqueIndexToRequests < ActiveRecord::Migration[5.2]
    def change
        reversible do |dir|
            dir.up do
                connection.execute(%q(
                    create unique index index_requests_on_interchangable_sender_id_and_receiver_id on requests(greatest(sender_id,receiver_id), least(sender_id,receiver_id));
                    create unique index index_requests_on_interchangable_receiver_id_and_sender_id on requests(least(sender_id,receiver_id), greatest(sender_id,receiver_id));
                ))
            end

            dir.down do
                connection.execute(%q(
                    drop index index_requests_on_interchangable_sender_id_and_receiver_id;
                    drop index index_requests_on_interchangable_receiver_id_and_sender_id;
                ))
            end    
        end
    end
end

Code explanation

After creating the migration file, the reversible is to ensure that we can revert our database whenever we must. The dir.up is the code to run when we migrate our database and dir.down will run when we migrate down or revert our database.

connection.execute(%q(...)) is to tell rails that our code is PostgreSQL. This helps rails to run our code as PostgreSQL.

Since our “ids” are integers, before saving into the database, we check if the greatest and least (2 and 1) are already in the database using the code below:

requests(greatest(sender_id,receiver_id), least(sender_id,receiver_id))

Then we also check if the least and greatest (1 and 2) are in the database using:

requests(least(sender_id,receiver_id), greatest(sender_id,receiver_id))

The request table will then be exactly how we intend as shown in the image below:

And that’s it. Happy coding!

References:

Edgeguides | Thoughtbot

If you’re reading this article, you already know that the benefit of open source contribution abounds. You can skip the article and navigate to the end if you’re here for the cheat sheet.

The common problem faced by aspiring open source contributors is how to take the first step from fork to pull request. After reading this article, you should be well equipped with all you need to make your first open source pull request.

Apart from making the process easier for you, the git workflow defined in this piece also makes your contributions look professional. This is especially useful in case you want to add your open source contributions to your portfolio.

Prerequisites

_Photo by [Unsplash](https://unsplash.com/@randyfath?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Randy Fath / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This article assumes you already know the steps to take to contribute to open source. If you don’t know, you may want to read this article written by Maryna. This piece also assumes that you’ve already setup Git on your PC. If you haven’t, you may want to check the setting up Git section of this article and do that first.

Step 1: Fork the project

This is as simple as clicking a button on GitHub. Navigate to the repository of the project you want to contribute to, then click the fork button at the top right corner as illustrated in the picture below.

After using the fork button, you’d now have the repository on your GitHub account.

Step 2: Clone the project to your local machine

This is the simplest part of Git. Navigate to your forked repository (the repository is now one of your GitHub repositories). Follow steps 1 and 2 as shown in the image below to copy the clone address. This address should look like this: https:[github.com/suretrust.com/freeCodeCamp.git](http://github.com/suretrust.com/freeCodeCamp.git)

Then, clone the project by typing git clone <the copied address> into your command terminal as shown below:

git clone [https://github.com/suretrust/freeCodeCamp.git](https://github.com/suretrust/freeCodeCamp.git)

Step 3: Create upstream

The upstream is necessary to keep track of the difference between the forked repository that is on your Git account and the original repository. This is most useful if you want to contribute to a popular repository.

Some repositories merge pull requests hourly or less, so be safe and assume that the forked repository you have will be behind the original repository.

Note that the upstream is in the freeCodeCamp repository and not your forked repository. Follow steps 1 and 2 as shown below to copy the upstream address:

To create a link to the original repository, copy and paste the following command into your terminal:

git remote add upstream <upstream address>

You can use git pull upstream master to confirm if there has been any change at the moment (from when you forked the repository to now).

Step 4: Create the branch you want to work on

_Photo by [Unsplash](https://unsplash.com/@zachreiner?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Zach Reiner / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

It is nice to create a new branch whenever you want to contribute. This illustrates that the branch is only for that contribution you are about to make. It could be as small as fixing a typo or as large as implementing a new feature. Either way, it’s good practice to create a branch.

Another important part of the branch creation is naming. It is pleasing to use a name that a stranger who knows nothing about the repository can easily understand. If you want to add a login feature, for example, you could create a branch called add-login-feature or login-feature.

To create a branch type the following command into your terminal:

git checkout -b <your branch name>

This command will create the branch and navigate into it. If your branch name is login-feature, then you can use the following command:

git checkout -b login-feature

Then add your contributions. After adding your contribution, move on to Step 5.

Step 5: Git add and commit your contributions

This is quite simple as well. Stage and commit your changes by typing the following into your terminal.

git add .

git commit -m 'Commit message'

Now, you have the changes staged and committed. What next?

Step 6: Pull from upstream to the branch

As I explained in step 4, this step is to merge any difference in the upstream into the branch so as to prevent conflicts.

git pull upstream <branch name>

This merges the upstream changes into your current branch.

Step 7: Push to the branch you’re working on

Now, you are almost there. Push your changes to the branch you are working on as shown below:

git push origin <branch-name>

Step 8: Open a pull request

This is the final step for any open source contribution, you are simply saying ‘I have made some changes, would you mind adding it to the project?’.

You open a pull request and if the repository owner or members like what they see, they’ll merge it. Otherwise, they could make changes then merge or request for changes.

To open a pull request, navigate to the forked repository as shown below. You’ll see your last push branch ‘login-feature’, then click on ‘compare and pull request’.

Explain clearly, the changes you made, then open a pull request as shown below:

And that’s it. :) You can now go ahead and contribute like a PRO!

Git cheat sheet for open source contributors

Peace out and happy contributing!

Typing a class or id selector several times within a single CSS file, or having to copy and paste every browser’s support prefix to your code each time for cross-browser compatibility can make your CSS file harder to maintain.

A CSS code sample

// cross-browser compatibility

-webkit-transform: $property
-ms-transform: $property
transform: $property

display: -ms-flexbox;
display: flex;

-ms-flex-wrap: wrap;
flex-wrap: wrap;

The next time you want to write CSS, try not “writing” in CSS at all.

Instead, try using CSS Preprocessors.

What are Preprocessors?

According to MDN, a CSS preprocessor is a program that lets you generate CSS from the preprocessor’s own unique syntax. You write your CSS code in them and then generate a corresponding CSS file to style your HTML.

Some of the popular preprocessors to use include SASS/SCSS, LESS, Stylus, and PostCSS. I use SASS, so my illustrations in this article are in SASS.

Though preprocessors have their own syntax, they are quite easy to catch up with, just a few differences from writing vanilla CSS.

6 Reasons Why You Should STOP Writing CSS in “CSS”

Preprocessors’ syntax gives room for some additional functionalities that deliver the following:

1. Variables

Preprocessors use variables to store reusable values. You can store any type of styling in a variable. It could be color, font-family, or even values for your padding, margin, width, or height.

When you define the variable, there is no need to remember the value. Recall the variable whenever you need the stored value.

// variables

$my_font: Helvetica, sans-serif
$my-color: #333

body  
    font: 100% $my-font
    color: $my-color

2. Nesting

We write HTML by nesting child/children in parent elements like the ul, li, and a element in a nav. When using preprocessors, you don’t have to write out the parent CSS selector (nav tag in this case) each time.

Move to the next line and type the child element as shown below:

// navigation bar

nav
      ul
        margin: 0    
        padding: 0    
        list-style: none  

    li    
        display: inline-block

     a    
        display: block
        padding: 6px 12px
        text-decoration: none

The ul, li, and a selectors are nested inside the nav selector.

Some developers believe this is coming to CSS. But hey, it’s not here yet, it doesn’t hurt to get used to it before its arrival in CSS. :)

3. Import

Preprocessors make CSS’s existing import better.

import lets you split your CSS into smaller files for readability and maintainability. It takes the file you are importing and adds it to the file you are importing into.

// _reset.sass

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote    
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font: inherit;
    vertical-align: baseline;

You can import the reset.sass file as shown below:

// main.sass

@import reset

body
    font: 100% Helvetica, sans-serif
    background-color: #efefef

This means you can have the main.sass file, then others like reset.sass, header.sass, footer.sass, or variables.sass. You import other files into the main.sass using the preprocessor’s import syntax.

The imported file is then added to the end of the main.sass file (the file you imported into).

4. Extend

extend stores a styling or series of styling into a class. It works like a variable. It uses a placeholder class (%) to tell the compiler not to print the class unless extended.

When the class is extended into an element, then the element inherits all the styling properties saved in the placeholder class. You can still add unique styling if needed.

// This CSS will print because %message-shared is extended.
// "%" illustrates the placeholder class

%message-shared
    border: 1px solid #ccc
    padding: 10px
    color: #333

// This CSS won't print because %equal-heights is never extended.

%equal-heights  
    display: flex
    flex-wrap: wrap

// This extends without adding any other styling

.message
    @extend %message-shared

// These extend with additional styling (green, red, yellow)

.success
    @extend %message-shared
    border-color: green

.error  
    @extend %message-shared  
    border-color: red

.warning  
    @extend %message-shared
    border-color: yellow

This saves time and keeps your CSS clean.

5. Arithmetic Operations

Preprocessors allow you to run arithmetic operations in your CSS. It supports standard mathematical operators like +, -, *, /, and %.

// Arithmetic operations
.container  
    width: 100%

article[role="main"]  
    float: left
    width: 600px / 960px * 100%

6. Minification

Minification reduces your file size to speed up load time. It removes white spaces and unnecessary characters from your code (CSS in this case).

Preprocessors allow you to generate a compressed version of your CSS. I know there are several other ways to generate this, but hey, this is cool as well. :)

Conclusion

Having to use the terminal when compiling is the main downside of using preprocessors. However, there are other ways to compile, such as using CodeKit, Compass.app, and GhostLab. There are now some in-editor plugins (like Live Sass Compiler on Visual Studio Code) to help with this as well.

Try out any preprocessor of your choice. I bet you won’t ever write CSS in “CSS” anymore. If you have been using preprocessors, share your experience in comments.

Peace out and happy coding!