Frontend 1x1 for Backend Devs

For developers, who are not working on the frontend, but would like to get at least an overview there.

In this article I will provide a first insight into a typical frontend project and thereby help you to orientate yourself there a little bit. Even if you see your focus in other areas of the application, you can't avoid the frontend from time to time. Fortunately, there are a few standards that you can use as a guide.

So we take a view how to set up an existing frontend application locally and then start, test or build it. In all steps there is the risk that it was of course solved a little differently in the respective project. In many cases this can be discussed, but we assume that the developers have their reasons. So if your project differs from what I write here, you'll have to ask your colleagues.

Starting point: package.json

Build and dependencies in most projects are configured using the package.json, which should be in the root of the (frontend) project. It contains some meta information about the project like a name, sometimes a version, necessary dependencies and scripts to build, start and maybe test the project. Often it also contains the configuration for used tooling, but this can also be in a separate file.

A good start is to install all dependencies first and that's where things can get exciting.

The correct node version

Basically you should ensure that you have the correct node version installed. Usually this version is defined in the project, e.g. in the documentation, a readme, the package.json or an own configuration file (.nvmrc). I have been managing my node versions with nvm for several years now and I am very satisfied with it. If there is a .nvmrc in the project, you can use nvm use to select and install the correct Node version. Otherwise I would use the current LTS version. The nvm documentation is excellent and describes all necessary steps.

For most frontend projects, the use of the correct node version is not mandatory "just to start or test everything", you should just not commit any changes to the code afterwards, which could arise, for example, during the installation of the dependencies. The same applies to the next step: the Package Manager.

The correct package manager

As with the Node version, there are many different opinions and in this article I don't want to go too deep into the topic of package managers. Node comes with npm (for me the main reason to use the right Node version) and in many projects this is enough to "just start everything". As with the node version, it should be documented which tool is used in the project. Mostly this is either npm or yarn, but there are also many other tools here.

If the project has a package-lock.json next to the package.json, this speaks for the use of npm. If there is a yarn.lock there instead, yarn is probably used. Of course there are also projects that contain both files or neither. In both cases I would question this critically, but this can also be an issue in the project.

The fallback solution of my choice now would be the "standard" npm again though I would also watch what happens in the repository. I would also undo all changes and delete the node_modules folder again when I'm done.

Install dependencies

Dependencies can be installed using npm via npm install or yarn via yarn. Both should be executed in the folder where the package.json is located. After that a node_modules folder should be created in the same folder, that ( hopefully ) is also in the .gitignore.

At this point you may get an error if the used dependencies are in a separate repository and npm has to be configured. This should also be part of a normal project documentation and mostly just means that you have to create another .npmrc in one of the parent directories of the frontend project.

Now you can start, build and test the project by executing the appropriate scripts.

Start, test and build projects

This brings us back to the package.json in which there should be a block scripts. These key-value pairs describe the scripts that are supported in the project (this is the respective key) and what they do (the respective value). Even if I use npm in examples now, you can also use the package manager in use analogously:

To start one of the scripts now, run npm run <key> in the terminal. Let's assume our package.json contains only one script to run tests and uses jest for this:

"scripts": {
   "test": "jest"
}

Using npm run test I can execute this script. The tools installed in the project (which we already have done) are attached to the PATH by npm and so can be easily used within scripts.

I would expect scripts to start and build the project here now. In most projects that I've seen, the names are quite speaking, otherwise a look at the documentation or the coffee with your colleges is also recommended here.

I hope this little guide helps you with your work. What else would you be interested in? Where do you hang out when working with frontend colleagues? Feel free to write me on Mastodon or Twitter.