Sane tooling for the Frontend engineer commoner

Note: This guide is without much fuss and shiny things, it focuses on becoming most productive on your day to day projects and making yourself and your team happy

Why read this guidelines ?

In modern JavaScript environments, more time is spent initially on the tooling aspect than it is for actual implementation when you want to kick-start/jump on a project/feature. These tools might range from linters and beautifiers, to specific code editors and plugins. There is a huge number of choices and an unlimited amount of combinations that someone might choose to adopt. But all of these tools have their own characteristics and learning curve, requiring a fair amount of time to familiarize and consequently become effective with.

This makes it clear that if we hope to adopt a common quality baseline and "way we work" across teams and organizations we need to have at least some reasonable defaults in the tooling aspect. The propositions below are not strict but they can act as a good starting point. Again, new additions and enhancements should be more than welcome.

What's in the box?

• Code Editor /w plugins
• Beautification & Linting
• Git Hooks
• Code quality rules

Code Editor

Our editor of choice even as a starting point would be VSCode. This is an editor and not a full-blown IDE as the name suggests but with all the plugins and community support, it can quickly become IDE-like. Some of the benefits that this editor provides out of the box are:

• Lightweight (at the beginning)
• Customizable
• Mostly focused on JavaScript and friends development
• Extensible
• Built-in integrations with git, debugging, IntelliSense, command line interface and more.

As you can also understand pretty quickly it is backed by Microsoft so there is not imminent danges of becoming a left out project. The community is great and the development efforts going on are really mind blowing. I predict that if it hasn't already, it will become a de-facto for most generic development efforts (except for Java which IMHO is not ready yet).

Extensions

One of the core features that make this editor a pleasure to work with, is the plethora of extensions that you can find and download without leaving your editor interface and most of the times without even reloading the application.

I have promised to you that this guide will only include the sane choices and no fluff so I will be quick.

• Live Share: This extension for me is the number one thing that you should integrate not only in the editor but also in your team culture. You can share the editor interface, file structure, the console and even the local development server through it. In my company we use pairing, presentations and code inspections extensively.
• Document This: Even is we want to follow our great naming conventions for classes, functions and arguments, we all can familiarize with the fact that it is really nice to inspect code that has clear and familiar documentation. It will save you so much time. Please also read this article to be enlightened on how you can integrate a type safety on regular JS only with JSDoc comments in VSCode.
• ESLint & Prettier: These too are they main pillars for our beautification and linting rules. VSCode has first class support for both of those.
• GitLens: The best git extension I have found as of yet.
• Import Cost: Everytime you import an external dependency into your project files, this extension will show you the size (in kb) that you are adding on your dependency tree for the application. This might seem as a "Nice to have" but when going to production grade, these things matter. Personally, having worked with these for quite some time, I feel kind of naked without it.
• TODO Highlight: An extension I personally find interesting, providing you with intentful additions to your comments. Really cool that you can just list all your code TODOs, FIXMEs etc.

Extensions for technologies that we are stuck with:
Let us not forget that many of us, will get to work in an application that has some history marks on it. For example ours is CoffeeScript, for you it might be Jinja or something. But we would not falter or bark at our colleagues that had to make a decision which seemed reasonable at that time. So we go ahead and install

• Coffee Lint

Beautification & Linting

For linting we chose ESLint as the default code linter for our projects. ESLint is the most popular, battle-tested and also extendable of the available JavaScript linters. I would propose that you define (together with your team) a set of rules that can be generic to most projects you will undertake and then just go ahead and install it as an npm package as we have done with our own.

The ESLint plugin setup can be enhanced to be chained together with the use with a beautification tool and that tool is Prettier. This allows us to never have to care about having the same styling conventions across our codebase.

There is nothing more confusing and uncomfortable than having to review a Pull Request that also includes styling changes.
To configure beautification rules, options can be added on a .prettierrc file at the top level of the codebase. An example configuration that we use in our team for most projects is the one following:

{
  "trailingComma": "es5",
  "tabWidth": 2,
  "semi": true,
  "singleQuote": false,
  "bracketSpacing": true,
  "arrowParens": "always"
}

The integrations with VSCode that these tools have can be configured to run as we are developing, warning us about dangerous/erroneous coding practices or automatically formatting our code after saving a file. (Highly recommended)

Git Hooks

As we have integrated automatic linting and beautification on our projects, it would be a shame if we accidentally commit code that is not up to these standards. To make sure that this is the case, we have setup specific git hooks that allows us to run custom procedures before each commit, push or any interaction on the version control lifecycle. To setup this kind of automation in the easiest way possible, we use the husky npm package which allows us to configure git hooks directly from the package.json file.
For now these hooks make sure that pre-commit the code is formatted but also will not allow any code that is considered erroneous by ESLint. That means that to commit code to the repository it must adhere to our project's coding standards.

Code Quality

So this is a difficult one as most will argue that any ruleset can guarantee Code Quality. But I think we can make up for a few things that will save us many headaches in the long run. Of the things that I have found most useful is rules based on a term called Complexity and it can be included through ESLint. I would suggest you look more into this concept and I do not usually prefer it but the Wikipedia article on this is quite good. Here you go with the ruleset we are using:

{
    "complexity": [2, 5],
    "max-statements": [2, 7],
    "max-statements-per-line": [ 2, { "max": 1 } ],
    "max-nested-callbacks": [2, 2],
    "max-depth": [ 2, { "max": 2 } ]
}

These rules are set to prevent us from committing code that is difficult to test, understand, review and reason about. These statements might seem a bit strict initially and can really prove quite bothersome at times but we should not falter. Except for testing our own competency and skill on the tool we are using daily in order to get better, we can also brag about it on other social platforms.

It is all about effectiveness

Anyone can argue that this is just another setup. It really is, but it is one that on our team we have found combines most of the nice stuff that we can get to make the best out of our development experience especially at work. I hope you can get a thing or two from this and I would really like your suggestions and feedback down in the comments section.