Welcome to The Developers’ Side of The Linkers!
Hi! My name is Michael Yegorov, I’m a senior frontend developer at Linkers.
Today we announce a new section in this blog, which is devoted to our wins and fails (lessons learnt 🙂 ) from a technical perspective.
As a company that integrates and supports digital workplace and online community solutions, we’re constantly fulfilling our clients’ requests on improvements and customizations. Over those years we went far beyond the point where there were only a few CSS tweaks and some jQuery code here and there. Now we’re building full-fledged products, just on top of certain platforms’ ecosystems rather than doing standalone applications.
It is not a rare case when a client’s story requires creation of a single-page application with tens of views, routing, middleware with complex database interaction, single sign-on, integration with other 3rd party services and so on. And on top of that, this SPA has to be seamlessly integrated into one of our supported platforms, such as SharePoint & Microsoft 365, Verint, LumApps, etc.
Obviously, as the software we’d created was becoming more and more sophisticated, we faced the issue that old approaches no longer worked or were causing a lot of technical debt.
Linter-Hinter
In this series of articles I’m starting now we will tell about the path we went through, development tools and methods we applied and how exactly all of this helps us create reliable and maintainable products.
This, although, will not be a completely chronological story. For the first entry we selected one of the most recent code quality measures. They include a few levels, one of which is the code style and quality checker known as linter.
Linter is a tool that programmatically analyzes software source code using the collection of specifically configured rules and tells if there are any potential problems. The process can be done both after the work is done or on the fly, when you are actually writing the code (in that case the job is done by the IDE that utilizes the linter tool automatically). What’s also important is that the same tool can be included in automations of development and deployment pipelines, company-level code quality surveys etc.
Why bother with linter?
Why is linting important? Of course it makes your code tidier. Clean and well-structured code improves readability, which is especially important if the code is maintained through several years by different people. But it’s not just that.
Fixed code style, for example, is making code reviews easier – first by automating the surface level of the review, then by ensuring that the only changes are the meaningful ones, not accompanied by hundreds of alternative formatting that different developers (or their IDEs) prefer.
But what’s more important, many ESLint rules are preventing actual errors, “code smells” and anti-patterns. In this way, linter fixes bugs even before they become bugs!
Our approach to linter kick-off
Our first thought was just to apply the widely spread StandardJS or another popular ruleset. It was better than nothing and it brought some results right away. But after testing them we realized that we couldn’t just stop at that. Some of the popular rule configurations were just irritating, for example causing the whole page to be underlined in red, because the code was just in the process of being written.
So we decided it was time to “reinvent the wheel” and develop our own code style.
We’ve actually done quite a lot of work: we analyzed each rule one by one, reviewed every of its possible options, compared them with the corresponding configurations of other popular presets and made a decision. Sometimes we actually had quite an argument about some nuances, but our final goal was not to prove our point or make our developers suffer, so we didn’t end up fighting 🙂
Main requirements to our ruleset
- It must be very strict when it comes to the “Possible Problems” section of rules. This section covers real errors, like reassigning the constant, but also situations caused by inattention – like the rule that Array.map function should always return a value, or by bad understanding of used mechanisms, like the one that prohibits Promise executor function to be asynchronous.
- It should be more lenient in rules that are easily auto-fixed by ESLint itself. This is something StandardJS and other presets definitely lacked. ESLint has two levels of reports, Error and Warning, for a reason. If some rule only relates to code formatting and is automatically fixed – why should we annoy the developer with it, telling it’s an actual error and painting the code red? It’s much better to just have a practice of running –autofix command on file save (a feature that the IDE we use, WebStorm, easily automates).
- It should not only take care of obvious local code problems and formatting, but also help us improve our products’ structure on a larger scale. This is why we eagerly adopted ESLint metrics that help detecting redundantly complex code, long functions that try to “do it all”, excessive nesting of the HTML code etc. In this way we made linter to give us advice on when the component should be split in two, or the function code should be simplified for better readability.
Applying linter to our projects
Another important note is that for some rules we made different configurations for new code and legacy code. Following some rules can make you rewrite the entire portion of code, which means this code should be put to regression testing – new code means new bugs.
Next thing we did is the open testing of the ruleset, where our developers were encouraged to apply it to their code and give their feedback. And then, when it was approved, we started applying our new rules to working projects step by step.
At the moment it is a requirement that for all our new projects we apply the new ESLint configuration, for example it’s included in our Yeoman scaffolders. For those projects that don’t have a scaffolder, part of the code review process is to ensure that the new style is applied.
Some of the existing projects are being gradually moved to the new style too. Our approach is that we apply linter to the old project when it’s about to receive a new update. When it’s done – it’s critical to solve all error-level reports, but when it comes to warning-level, the action is decided based on how much spare time we have on that update. If the client’s deadline is tight – we can decide to omit certain warning-level reports and return to them later. In this way we can move to the new code style bit by bit, without breaking the flow of the work or delaying the delivery.
What’s next?
Of course, our work on the linter ruleset doesn’t end with this. We have plans to develop it further, adding new plugins that allow to control more aspects of how code is written. But the majority of work is done and we can do the future upgrades in the background.
In next articles I will tell about some specific rules or their combinations that caught our special attention or caused the most discussion – it’s educational to understand why exactly they were controversial.
