DEV Community

Cover image for By "Linter/Formatter" do you mean Eslint/Prettier?
Dan Calderon
Dan Calderon

Posted on • Edited on

By "Linter/Formatter" do you mean Eslint/Prettier?

When I met some of the devs who would work with me on a new project, I asked them some small questions to be aware of their preference, experiences, and backgrounds.

They were mostly frontend developers with 2-4 years of experience, all of them worked with different stacks and had a good knowledge of the architecture and stack that I had in mind for the new project, but when I asked one of the more small and trivial questions, I got more questions than answers

What formatter and linter do you prefer?
By "Formatter and linter" do you mean Eslin/Prettier? πŸ€”

This was a valid counter-question since most of us always install eslint/prettier no matter the project or product, and never stop to think about other options.

This was a new project so I asked them if they wanted to try Biome as our new linter/formatter, and all of them agreed under the promise of "faster deploys" or an easy way back

Biome as an alternative to Eslint/Prettier

Biome -formerly known as Rome- is a library that intends to replace, or at least, compete with Eslint and Prettier, merging both functionalities in a single tool.

It is a tool built in Rust that could lint and format Javascript, Typescript, and CSS.

Biome prosπŸ’ͺ

  • Simpler configuration
  • It can be run without project installation
  • Faster to lint and faster to format the supported languages
  • Easier way to share the configuration between teams
  • Smaller packages
  • A single tool to deliver the same functionality
  • Migration from eslint/prettier to biome can be done with a simple script in a couple of minutes

Biome ConsπŸ’”

  • Not all the rules are supported or documented
  • It is a new tool and has a smaller community
  • It only supports a few languages at the moment, but the team is pushing to include more and they are working speedily.

And that's all, the cons seem pretty small when we compare them against the cons 🀩

Configuration πŸ”§

We can configure Biome with or without previous eslint/prettier settings

we just need to

pnpm add --save-dev --save-exact @biomejs/biome
Enter fullscreen mode Exit fullscreen mode

or we can even avoid the installation and use the Vscode extension.

Biome will use the default configuration and rules for us.

We can create a biome.json where we would store the configuration and rules

//biome.json

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

and that's all that Biome requires to run the configuration, it will detect the path in the root of our project and run the linter for us.

But what if we already have some prettier/eslint configuration that we don't want to lose?

Well, that would be as easy as running a simple migration script provided for the biome team and available to use if we already installed the tool in our system

biome migrate eslint --write
biome migrate prettier --write
Enter fullscreen mode Exit fullscreen mode

This script will read the prettier/eslint .json files and parse the rules into biome rules for us, even the rules from eslint pluggings that we are extending in the eslint.json configuration.

once that script is finished, we are set and done, we now use biome in our project

Run on saveπŸ’»

If we are using vscode, we would just need to disable eslint/prettier extensions, be sure to install and enable biome extension, and then just go to the type of file that you want to enable biome, do β‡§βŒ˜P search the "Format document with" > Configure default formatter > select biome

This will set biome as our formatter for the type of file, allowing us to just use it where we want

We can add to the vscode settings

"editor.formatOnSave": true,
Enter fullscreen mode Exit fullscreen mode

and we are ready to run biome for use on save, and you would probably notice the time difference immediately

What about Github actions?πŸš€

Well, that is also covered in an easy way

Just go to your .github/workflows directory and add the pull_request.yml

name: Code quality

on:
  push:
  pull_request:

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Biome
        uses: biomejs/setup-biome@v2
        with:
          version: latest
      - name: Run Biome
        run: biome ci --config-path 'configuration path in the project' 'what files should format/lint'
Enter fullscreen mode Exit fullscreen mode

In our case, we probably want something like this

biome ci --config-path './' './src/'
Enter fullscreen mode Exit fullscreen mode

This would use the configuration in the root of our project and run biome in all the supported files inside the /src directory

In our project, we tested the build in GitHub with eslint/prettier vs biome, and it went from 7 minutes to 1/2 minutes🀯🀯

Maybe 5 minutes doesn't sound that much, but when you add them for every pull request and every update on those pull requests, it starts to sound a little higher.

And when you think about the automation tool times -cypress in our case- and how much money we could save reducing the times of linting and formatting, those 5 minutes started to sound even better

So, yeah, not only the team is using biome at the moment, but now we are all aware of what is a linter/formatter and why is it important to have alternatives in each aspect of our application build process as developers.

Top comments (0)