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
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
}
}
}
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
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,
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'
In our case, we probably want something like this
biome ci --config-path './' './src/'
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)