DEV Community: Pamela Peixinho

Progressive Lint: How to continuously improve the codebase

Pamela Peixinho — Mon, 07 Jan 2019 15:41:00 +0000

TL;DR — How I stopped wasting my time breaking all the apps : I built a solution to improve the entire codebase during the development workflow. This post shows the usage , how to setup and start using progressive lint mechanism

Before we get started, this article is a continuation of a previous article that explains how to Build Scalable Code Style in a JavaScript Codebase. I truly recommend reading the first before continuing this one.

How To Build Scalable Code Style in a JavaScript Codebase

Have you ever broken any application trying to improve it? Or have you ever applied a new lint rule and spent a lot of time fixing the code?

I’ve been through both situations. Progressive Lint helped me to avoid those pitfalls moving forward.

So, in this post, we’re going to see:

The problems that we faced when we weren’t using a progressive approach
Real world use case at QuintoAndar
How to set up progressive lint

Let me tell you a story of how I broke some apps trying to make them better…

First of all, I’m known as “lint addicted” in my work at QuintoAndar, because I always get small details in code reviews and I really really like eslint. (As you can see, this is my second article about it _😅)_

However, it’s impossible to predict all the rules before you start the project. This happens because some of them will be chosen later, or a new rule or pattern was decided later. There’re lots of reasons to update it later.

So, it’s necessary to do improvements when the project is already live. It’s like: Fixing the plane while flying it.

I wanted to fix while the project was live, but my mistake once — by once I mean a couple of times — was that I was trying to do this as a one time job.

Sometimes, I got a project that I've never worked on and applied eslint settings, from zero or only the new rules. Of course, It didn't end well.

I tried to take care. I ran the tests, ran the server locally, rendered some pages and called some endpoints. But still, some “planes” crashed.

After I successfully failed with some applications trying to make them better. I realized that it was costing more than I expected, so, it wasn’t being worth it.

It costed so much of my time! But, the worst part was that most of the time I needed to redo my work. Other developers were working on the same project, and time and time again I needed to rebase and resolve conflicts 🙄.

I understood that this approach wouldn’t scale. Plus, we have a Design System and specialized guild for Front-end, which means we’re usually working on new patterns and how to do things better.

There will always be more projects and more rules to apply!

Thus, I needed to find a way to do it progressively. That's what I did! For my surprise, it was simpler than I thought at first.

What’s the idea behind a progressive lint?

We just need to run the new rules in the modified files in the feature branch. This way, applying new lint rules is part of the workflow of each software engineer that’s working on this project.

Yes, even if the developer does a minor change in the file that contains something that violates the new rule, she/he is going to be forced to fix the entire file.

By the first look, it can sound bad because of the context switch or blocking the person to finish the task, but allow me to be cliché right now:

All software engineers working together on it in the normal workflow, makes us achieve more! It’s so much more scalable.

Do the other Software Engineers like it?

Now, you may say:

Ok, it worked, but.. does the software engineer like it?

Hmm, I answer:

It worked, but ‘like’… that’s another thing!

I’m kidding! 😛

Everytime that anybody sees some error of the progressive lint, we always get bored like “Oh, Do I really need to fix it?! 😒”. But the truth is most people complain and don’t like it at first, but none of them argue it is not worth it.

We know that it’s going to arrive the day that we fixed all code is up to this rule and a new one is going to come!

The results make us excited to do it and see the code quality always improving!

Our real current usage

We are still working and improving it, but we already did some pilots by now. And new rules are coming in which we’ll use the same approach too.

The pilot of progressive lint was to deprecate a component that we used to use. The name of it was Typo, and we needed to stop using it and start using a new one that was better aligned with the design system.

First, we tried to create a task force cross teams and treat as one time job, but as you can imagine that didn’t work. So, it was a good opportunity to create progressive lint and use it as a pilot. We created a new rule and put in the progressive mode.

What happened? It worked!

Every time we change a file that has an import of the deprecated component, we need to update it to use the new one! 😉

And we continue… We recently added another rule for file naming that is working. And coming soon: more rules about imports, components and best practices!

Therefore, my friendly advice is: If you’re not doing things using a progressive approach. You should start doing it and analyze the results!

So far we know the costs and benefits of the progressive approach. Let’s see now how you can do that for your project.

How do we do progressive lint?

First, we need to add another script inside our package.json to run the command of progressive lint.

The main difference is that we need to add the config file for the rules that are going to be applied. Like the script below.

After that, we need to create the referenced file that specifics all the rules/settings that you want to apply in a progressive way.

Then, we need just run the command with this script in the changed files. The best way we found so far was this:

This file should represent the CI file where we put the commands that should run. In this case, I'm putting a yml with the drone syntax, because we use drone at QuintoAndar, as you can see in this article.

So, in the first command, we just fetch the base branch in this case (master) after we get the changed files using GIT.

git diff --name-only origin/master

The command gets all the names of the files that were changed compared with the base branch. To specify, we just want Javascript files, so we pass the result of the command above as input of the next command:

| grep '.js\*$'

Last, but not least, we run the command of progressive lint that we did, passing only the changed files as params to eslint.

npm run lint:progressive $FILES\_CHANGED

And that’s it…

With a few lines, we made progressive lint part of our workflow without pain, rework or breaking the app! And this can only be achieved with all software engineers working together ❤️

Join Us

If you like challenges and you want to work in a startup that is redesigning the entire experience of the rental process . Using technology and design as the core components. Look at our job opportunities on our career page, we’re always looking for talented and eager to learn people.

Work@QuintoAndar

Tks for reading! I’m always open to receive feedback, recommendations or questions, feel free to contact me!!

LinkedIn : https://www.linkedin.com/in/pamepeixinho

Twitter : https://twitter.com/pamepeixinho

GitHub : https://github.com/pamepeixinho

Website : https://pamepeixinho.github.io

My last name is Fishie, I swim and code sometimes. “Sea” you later! 😉

How To Build Scalable Code Style in a JavaScript Codebase

Pamela Peixinho — Mon, 07 Jan 2019 15:41:00 +0000

From the messy codebase to the new era of consistent quality across the company

"I will not write messy code." (Reference)

Have you ever needed to develop in a messy codebase? Have you ever switched projects and felt lost because of the different standards?

Everyone has probably been through one of those scenarios. We have been too, but we have found ways to improve code style consistency across the company.

These are the main challenges that led to an inconsistent code base that we had to deal with:

many developers in a unique project
many developers in many projects
specifics company needs (like customized rules to be followed)

First, let me start with a story…

In September 2017, we released the first QuintoAndar PWA (Progressive Web App). Which means that we basically rewrote the entire front-end application that existed before.

(I was part of that team, it was an amazing experience! I’ll tell it in another post someday)

One year after the release, we now have about 10 PWAs. All of them using the same stack: React + Redux and reusing code between projects.

We already had a glimpse of how bad things could get on our legacy website if things weren’t kept in check, and we definitely didn’t want our shiny new project to go the same route.

As everybody knows, JavaScript is an amazing programming language with thousands of libraries and different projects around the world. However, JS world is not really perfect! But if I had to summarise the main point of contention:

“The best and worst of javascript is the lack of constraints that allow us doing everything we want”

We have so much “freedom” with JS, which is amazing because we can create a lot of things. However, it’s dangerous too! Just imagine many developers being able to do whatever they want in a single project without any kind of standard /consistency.

It can turn into a mess as it was our old project. Messy code is difficult to read, test and maintain. This makes the project more “buggy” and harder for the new developers to onboard.

As a developer, I would prefer not to give that kind of “freedom” as we can get a bit too much creative!

For illustrative purposes only

So... How did we avoid making the same mistakes of the old project in the new ones? How did we prevent messy code?

We set boundaries to our own “freedom”! We put constraints on the project in order to make the code clean and consistent. It helps developers to be creative in solutions for the problems not for code style.

How did we set boundaries?

First of all, we enforced at least one code-reviewer in each pull-request! Unfortunately, this is not automated because it depends on humans, so it can’t scale as well and some errors and inconsistencies will pass!

For the task of automating we used code linters to check the code style and best practices. Thus, we can ensure that all JS files in a project will be consistent.

This leads to improved readability and maintainability of the code. It also helps to find syntax errors and have fewer bugs. Making this process part of CI is key to ensure that standards are kept during the entire development cycle.

There are code linters for almost any programming language, in JS, the most popular is Eslint*.

*If you want to know how it works internally you can see here and there are lots of articles about eslint as you can see [_here](https://github.com/dustinspecker/awesome-eslint)._

Now you may think:

Ok, lint.. Everybody knows.. Why am I reading this article?

We had to scale this solution to several projects and repositories and this can become a growing pain. As companies grow, so does the number of projects in JS, including back-end in NodeJS.

So, how to maintain the same code style and code quality for the entire codebase?

As I told before, we have 10 PWAs and an internal components' library too. On top of that, we have several micro-services in NodeJS. As we can see in the image below:

Thus, we truly understand the pain to try to maintain the same code style and code quality in the entire codebase.

Still, you might think that is not a huge pain because we can just copy and paste the eslint config and rules in ALL our projects .

It’s a solution, but obviously, it’s not the best one!

Every new config or new rule you want to put, you should go through all the projects replicating the same thing.

The real danger here is that you may forget to apply some change in one and when you see it, we’re not following the same code style again => inconsistent codebase 😑

For that, the best way to fix it is using a cool feature of Eslint called Shareable Configs.

Shareable Configs

All the eslint configurations of a project are in a file named .eslintrc.This file is an important part of your project and sometimes you may want to share it with other projects or people.

How can we share it?

Shareable config allows you to publish your configuration settings on npm. Allowing others to download and use it in their ESLint projects.

All you need to do is add it as a dev-dependency in your project and extend it in the eslint resource file.

There are lots of shareable configs in npm right now as we can see here. One of the most used is Airbnb’s. This is one that we use at QuintoAndar too, but we felt the need to add our own settings too.

Thus, we created our shareable config packages eslint-config-quintoandar. But as you know we have specific stuff to PWA (front) and some to our micro-services (back-end). That’s why we created:

eslint-config-quintoandar-base is the npm package that it’s common for everything in JS and uses NodeJS (see at GitHub).
eslint-config-quintoandar-pwa is another npm package that has the specific configurations to react applications. It extends the QuintoAndar base package (eslint-config-quintoandar-base) and adds the specific stuff (see at GitHub).

Feel free to use our packages, and we’re also open to contributions. Everything is documented. If you want to create your own, you may also use as a reference.

At QuintoAndar, we’re still working on those packages and the usage of them. But the results are visible , with this tool you can maintain the same code quality and application quality because we could use rules that help to find bugs and improve performance.

For example, one simple rule that helps us to avoid unnecessary loss of performance, forcing not to use arrow functions or bind inside the render of React components, like this (line 8):

The code above would not pass in our eslint and, consequently, break the build (CI) forcing the developer to fix it.

The example above is a rule that already exists on the package provided by Airbnb. In case you feel the need, like we did, to create rules for your specific scenarios you can create custom rules.

Custom rules

Sometimes you need to enforce a specific rule in your codebase that is not going to be relevant outside of your company or you need to create one that doesn’t exist yet in the many existing open-source plugins.

It’s really easy and simple to create a new rule.

You just need to use the AST (Abstract syntax tree) to find what you want to report and set the description of how to fix it. If you need a more detailed description you can find it atthis article or in eslint docs.

At QuintoAndar, a npm package with our custom rules:

eslint-plugin-quintoandar (GitHub).

In this plugin, we have different kinds of custom rules:

Rules that are applicable to every project of every company, for example:

A rule does not allow the use of target="_blank" without using rel="noopener noreferrer"

Rules that are applicable only for QuintoAndar, for example:

A rule created to deprecate an internal component that should not be used anymore, or it can be applied to functions or files too.

A rule to deprecate a file in your project is the simplest rule that you could make. You just need to assert the import like this:

As you can see, it's really easy to customize lint rules to comply with new necessities of your team or company maintaining consistency and code quality across the codebase.

So, the final solution for consistent code quality across the company was:

Add eslint in all projects
Create and use npm packages of shareable config for the company
Create new customized rules to comply with new requirements

Still, these steps won't solve the whole problem, because it now means that every new rule needs to be applied to all files in all repositories at the same time.

It doesn't scale and it's dangerous because we can break the apps. So, we need to figure how to apply the rule continually using a progressive way to apply them.

I've already broken some apps trying to enforce a new rule everywhere in one shot. However, I found a better approach. Do you want to learn about that?

See the next article that explains what and how we to use Progressive Lint and why you must start doing in this way.

Progressive Lint: How to continuously improve the codebase

Join Us

If you like challenges and you want to work in a startup that is redesigning the entire experience of the rental process using technology and design as the core components. Look at our job opportunities on our career page. We’re always looking for talented and eager to learn people.

Work@QuintoAndar

Tks for reading! I’m always open to receive feedback, recommendations or questions, feel free to contact me!!

LinkedIn : https://www.linkedin.com/in/pamepeixinho

Twitter : https://twitter.com/pamepeixinho

GitHub : https://github.com/pamepeixinho

Website : https://pamepeixinho.github.io

My last name is LittleFish, I swim and code sometimes. “Sea” you later! 😉

My VSCode World

Pamela Peixinho — Tue, 19 Jun 2018 03:13:01 +0000

Hi everyone,

I'm gonna talk about one thing that I’m usually asked at my work or events:

“Your VSCode looks different, what is this extension? Can you pass me these extensions?”

I’m still a beginner but I really like to customize and improve my code environment. So, I decided to write this explaining all the extensions, tricks, settings, and helpers that I use, instead of an article with "Top 10 extensions".

First of all, why VSCode ??

VSCode is an IDE from Microsoft. It’s free , open source and built with JS + electron. It’s good for all languages, but mainly for Javascript.

It's simple and easy to customize everything in VSCode as good as the autocomplete and debug.

Plus: IMO, VSCode is good for both, "frontenders" and "backenders" !!

Interesting Settings 1.1 Font
Useful for Everyone (Backenders and Frontenders) 2.1 IDE Settings and extensions 2.2 Version Control 2.3 Node/NPM 2.4 Lint 2.5 Test 2.6 Markdown
Useful for Frontenders
Other cool extensions

Interesting Settings

Font

The main font that I use is Fira Code (Monospaced font with programming ligatures). You need to install this font at your font system and enable it just adding to your settings:

// Set the font family
“editor.fontFamily”: “‘Fira Code’, Menlo, Monaco, ‘Courier New’, monospace”,

// Enable the font ligature
“editor.fontLigatures”: true,

Then, you have a font like this:

Useful for Everyone (Backenders and Frontenders)

Here's the extensions list of my VSCode world:

IDE Settings and extensions

Settings Sync

Sync all your VSCode settings across multiple machines. I always have this problem because I have work and personal notebook.

Synchronize Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces and Extensions Across Multiple Machines Using GitHub Gist

Settings Sync - Visual Studio Marketplace

Active file at status bar

It shows the full path of the currently active file in the status bar

Active File In StatusBar - Visual Studio Marketplace

Intellij Keybindings

For the people addicted for JetBrains Products too:

Port of IntelliJ IDEA Keybindings

IntelliJ IDEA Keybindings - Visual Studio Marketplace

TODO highlight

“It’s just highlight, why do you like it?”. Answer: It’s easy to find your TODOs with this highlight.

TODO Highlight - Visual Studio Marketplace

Spotify

vscode-spotify - Visual Studio Marketplace

SVG Viewer

“svgviewer.enableautopreview”: true,

SVG Viewer - Visual Studio Marketplace

Change Case

change-case - Visual Studio Marketplace

Import cost

Import Cost - Visual Studio Marketplace

Version Control

Gitlens

As the name says: it’s an extensions like “lens” for git.

Supercharge the Git capabilities built into Visual Studio Code — Visualize code authorship at a glance via Git blame annotations and code lens...

There’re a lot of settings to improve the git lens for your taste, for example:

GitLens - Git supercharged - Visual Studio Marketplace

Node/NPM

NPM Intellisense

Autocompletes NPM modules in import statements

npm Intellisense - Visual Studio Marketplace

Version lens

It shows package version information for NPM. It’s very good to see versions available and the package status.

Version Lens - Visual Studio Marketplace

Lint

ESLint

Integrates ESLint into VS Code. That’s extremely necessary for projects that use eslint (It should be all, if you want a clean code 😆). When you have this extension enabled and some eslint violation, your IDE looks like:

Every line highlighted shows error Lint errors it’s.

Plus: It’s easy to fix it using “Fix all auto-fixable problems” or enable to auto-fix when saving in the settings

“eslint.autoFixOnSave”: true,

ESLint - Visual Studio Marketplace

Test

Jest Snippets

If you use Jest as test framework, you should have this amazing plugin to help write tests faster.

The main snippets that I use is:

desc+[tab]: describe(() => {}
it+[tab]: it(‘’, () => {});

Jest Snippets - Visual Studio Marketplace

Jest

This is a nice plugin for jest users, it shows at the start of each it if it’s passing. However, I put a warning here, this plugin can slow down your IDE.

Jest - Visual Studio Marketplace