How to bring a project to life

Imagine the situation, you are the first day on a new project for you, where will you start? Describe your steps.

This is one of the popular interview questions for front-end developers. I don’t know what the person asking this question wants to hear, but I have an answer to its technical component and backlog for several months in advance.

Foreword

In this article, I will rely heavily on (carefully, subjective opinion, confirmed only by gut feeling and the number of repositories on github) the most popular statics collector – webpack… If for some reason another collector is used in your project, then it’s okay: analogues of the tools we are talking about are likely to be found in the search.

But my advice: if your project is not an npm module, switch the static build to webpack, it will be easier this way.

Metrics

The first thing to do is collect metrics. They will help you understand that the situation is better, not worse. You can start with the weight of the static (JS, CSS, HTML, images, etc.). This is done surprisingly simple: we collect the prod version of the project and get the weight of the files. The second important metric for us can be considered web-performance… It can be obtained using Lighthouse… We take measurements, save the estimates. And we are ready to start.

Unused files

We need to make our life easier by deleting unused files. They interfere with the perception of the project, and at times can be very confusing. For example, once I deleted the files for half a project, they were simply not used anywhere. To solve this problem, you can use a plugin under webpack – unused-files-webpack-plugin… We connect the plugin, start the build, get a list of garbage files in the console. The plugin has a parameter failOnUnused, the default is false… If you want to make the check strict, then change the value to true, and the assembly will crash if someone leaves an extra file in the project.

Static code analysis

We have deleted unnecessary files, which means we will not get into a situation where, after fixing a specific file, it turns out that it is not needed, and we wasted our time. The first thing I recommend to install on your IDE is the plugin SonarLint… He knows how to parse not only JavaScript, but also many languages ​​(full list here). Install, check the whole project, see errors, correct – profit.

This, of course, is not all. Now you need to install and configure ESLint… Let’s turn to the rather popular Airbnb config for help: if you don’t have React – eslint-config-airbnb-base, and if React – eslint-config-airbnb… They differ in a set of rules. For example, the package for React will contain rules from ESLint plugins: eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y… Some rules are a matter of taste, and if you do not like, for example, hanging commas, you can always change the rule setting.

The third step in our crusade for code style and codebase quality will be connecting eslint-plugin-sonarjs… The ESLint plugin does not replace the IDE plugin in any way, but only nicely complements.

In the first three steps, we focused on JS, but there are a lot of styles in front-end projects, let’s move on to them. For anything that is not Stylus, we will use Stylelint, and for Stylus – Stylint…

It is expected that there will be a bunch of bugs after implementing SonarLint, ESlint and Stylelint or Stylint. It is not necessary to edit everything at once, you can temporarily disable the rules and correct them in order, or reconfigure them before fixing them to warning.

Dependencies

Dependencies make up the lion’s share of the code in the project. First, it would be nice to know the tools we use. Secondly, these very tools can have a bad effect on web-performance your application.

The ideal tool for solving this problem is the webpack plugin. bundle analyzer… It will allow you to see what the application has under the hood, find the most difficult dependencies, as well as dependencies that should not have been included in the production build (for example, prop-types, redux-devtools, hot-loader, etc.).

But dependencies have another problem: they like to be duplicated. Mostly due to incorrectly assembled npm packages and the difference between major versions of npm packages.

A tool to help us find takes: duplicate-package-checker-webpack-plugin (yes, this is another plugin for webpack). Similar to the unused-files-webpack-plugin, it can be set to strict check and complete the build when a duplicate is found. To do this, set the parameter emitError value true…

What are we going to do with the found takes?

• Anyway, it’s worth freshening up all the dependencies.
• If this does not help, you can look for an analogue of the package that creates the problem. This can be done through the service bundlephobia…
• If there is no analogue, try writing the functionality yourself.
• If writing yourself is not an option, make a pull request.

Logging

After clearing the codebase of unused files, editing the style and dealing with dependencies, it is worth tightening the error logging. Perfect for this Sentry… She (he or it) was the de facto standard wherever I worked. There are two ways to install Sentry:

• script in HTML;
• as a module via npm.

I recommend installing by script in HTML. Why? Let’s say a user visits a website that uses fancy and modern JavaScript. The user has an old browser, and if he doesn’t understand the syntax, the user will get a broken application. After all, if Sentry was installed via a package, it will not be able to initialize to catch this error.

CI pipeline

We spent a lot of time, and in order for the project not to return to its original state, we need to automate all checks, trying to eliminate the human factor at least in these parts.

To do this, let’s write a few scripts in package.json:

"scripts": {
 "lint": "stylint src/ && eslint --ext .js,.jsx src/",
 "prod": "BABEL_ENV=production webpack --env=prod --progress",
 "build": "npm run lint && npm run prod"
}

What we get:

• JS linting starts (from package.json).
• CSS linting starts (from package.json).
• Webpack is launched (from package.json).
• The unused-webpack-plugin (from webpack) is launched.
• The duplicate-package-checker-webpack-plugin (from webpack) is run.

Web-performance

It’s worth taking the time to fix the bugs Lighthouse found (which I mentioned at the beginning of the article). In Chrome, you can check everything manually: switch to developer mode, and you will be taken to the Lighthouse tab. It is advisable to check in the mobile mode: if you get a good result in it, then everything will be fine in the desktop. You can also use CLI…

Summarizing

At the very beginning, I mentioned that the backlog will last for several months in advance. This does not mean that everything will take the same amount of time on all projects. This is rather the average for the hospital, given that most of the working time we solve business problems.

What we have achieved:

1. We cleaned the project from garbage.
2. Standardized the style of the code within the project.
3. Reduced the weight of the codebase.
4. Improved UX.
5. Set up monitoring.
6. Collected CI.

At a minimum, all of this can be used as an argument in your performance review.

PS

An example of a project with settings can be viewed at github…