Ultimate front-end project checklist

Kristaps Kazarevskis
Scoro Product Engineering
5 min readJul 28, 2022

There are certain routines and procedures that we are used to. And engineers are definitely rare creatures in following details and conventions. Should this variable be camelCase or snake_case, maybe even ALL CAPS? Should the import statements be ordered alphabetically? There are always personal preferences that don’t necessarily line up with those of other people, but when multiple developers work on the same project, it is crucial to discuss such things and find common ground.

At Scoro, we have come up with conventions that work for us, and after a while, developers get so used to them that they become second nature and any deviations can cause panic. Luckily, there are tools and automations that can take care of all the development processes like writing the code, validating the formatting, making sure the code is as clean as possible, tested and deployed to the production environment.

In this article I will introduce to you the conventions of a typical front-end project in Scoro. I know it may sound like a lot of work, but believe me, the developer experience will improve immensely as soon as you start using these tools. I suggest starting small, setting up Eslint or Typescript, figuring out the value and taking it from there.

Vue

https://vuejs.org/

There are many resources available for Vue vs React. At Scoro, we love them both, but our front-end stack is currently led by Vue. We are very excited about the new features Vue 3 brings and we would love to start using the script setup syntax, for example, as soon as it is possible for our production apps.

Initially we started out with Nuxt, which was great as well, but it turned out that we need our apps mostly in static mode and we were actually not using most of Nuxt’s features. This led us to use Vue on its own and set it up from scratch.

EditorConfig

https://editorconfig.org/

This small configuration file is read by the IDE and helps to set up the coding style without any effort from the developer. It’s very helpful when all the files in the project use the same indent and line ending styles.

Typescript

https://www.typescriptlang.org/

This is definitely a huge thing for us and there are no new Javascript projects in Scoro that wouldn’t use Typescript as well. Not only does it help developers to familiarize themselves with code very efficiently and understand the types of objects that are coming from the API calls, but the code can also be type-checked and bugs detected in the pipeline before the code is even merged into the target branch. It is extremely helpful to have a correct auto-complete and the ability to check the type of any object.

Eslint

https://eslint.org/

This guy has the most duties in our projects. Eslint analyzes the code, identifies the problems and even fixes most of them. This allows us to eliminate most of the bugs and we can see anything that is off directly in the code editor. We don’t even have to come up with our own sets of rules as the Vue team has already taken care of it. As long as the developer follows these recommended Vue rules, the code review process is much more efficient and most errors can be caught automatically in the pipelines.

Prettier

https://prettier.io/

We like things pretty, and more importantly, we like it when the code is formatted exactly as we intend it to be. While formatting the code itself can be very challenging and everyone in the team has their own preferences, this tool helps to solve this challenge right away. Once the team has agreed on what type of quotes to use, should there be trailing commas and so on, these rules are then applied by the editor automatically.

Style lint

https://stylelint.io/

This is pretty self-explanatory and as soon as the rules are set, there is not much else the developer has to do other than sometimes re-order the code, so that there are no duplicate selectors or some other similar minor things like unknown properties or incorrect color code.

Makefile commands

Oh, we do love these do-nothing scripts and utility scripts like “make setup” that run the environment checks, ask for some token, and in the end spit out a URL that you can simply copy and paste into the browser. Or something just as simple as “make up” to spin up the docker containers for us.

Testing

Yes, no feature gets merged without having been tested first and without making sure that all user flows are covered. At Scoro, we use the Jest environment but with a little help from the Testing Library. This library provides the utilities to render components into the DOM and for querying the elements, so we can test the feature in the same exact manner as the user would interact with the application. For example, if the user adds some text into the input field and clicks the Submit button, does the new item appear on the list? But what if the Submit button is clicked without entering any value into the input field?

CI/CD Pipelines

https://about.gitlab.com/

At Scoro, we have opted for using Gitlab. Moreover, the Gitlab pipelines are where we add everything that can be automated as well as run all the tests and builds to make sure that everything is correct before the feature code is even reviewed by peer developers. If everything is correct, the developers can focus on the important parts, such as code logic, and less on the formatting or unused variables.

Conclusion

So why even go through all this trouble of setting up so many things when the actual application feature code itself takes less effort than everything else around it? Well, because there are no such things as finished projects and people new to the project should never have to pay an onboarding penalty. Have you ever had to set up and run a project locally, but then it ends up taking all day, even though you had to make just one small change? And then it turns out that it actually breaks something in the production and you’re sitting there, pulling your hair out, trying to figure everything out, and this 30-minute task ends up taking all week? We prefer to be proactive about such scenarios and set things up properly right from the get-go.

If these tools and working in the most optimal way is something that speaks to you, take a leap of faith and check out our open positions at https://www.scoro.com/careers/.

--

--