Hi,
Recently, I was planning to integrate the ESLint rules into the CI/CD of a NodeJS backend. I searched the Internet and found that Airbnb’s Javascript style guide is quite famous. However, I being somewhat of a beginner in NodeJS, was looking for articles that would explicitly mention that this popular style guide can be used, as it is, in a backend NodeJS project too. I saw a few articles mentioning that it is very popular when it comes to ReactJS projects, however, not NodeJS. So I did my research and went through the rules mentioned in this Style Guide. I analyzed them if these rules are valid for a backend project as well, as they are for a front-end project.
When it comes to JS StyleGuide, the main difference between a NodeJS Backend project and a ReactJS project
Well! both, NodeJS and ReactJS, use Javascript, if you ask about the similarity. The main difference between these two is that code written in the NodeJS backend will be run on an environment controlled by the engineers who will deploy this project. On the other hand, the code written in the ReactJS front will be executed/run by the client-side web browser. Why does this matter in our case? Well! it matters because we as the engineers sitting behind the backend server can control the environment in which the code would be get run, but we cannot control the environment in which the code written in the ReactJS will run.
A client running the ReactJS code could be using a web browser that doesn’t support the latest ECMAScript versions.
How a rule might not be necessary for a NodeJS backend, but for a ReactJS front-end:
Well, there could be such rules which might not be necessary or would need different configurations in NodeJS backend than in ReacJS front end. Let’s take the example of the following rule (Github link):
// require use of the second argument for parseInt()
// https://eslint.org/docs/rules/radix
radix: 'error'
This rule comes into the picture whenever someone uses parseInt(arg1, radix).
It focuses on the 2nd argument passed to the parseInt, popularly known as radix, which specifies the number system to use. A radix=2 would suggest parsing the int value from the arg1 using binary as the number system.
Similarly, 8: octal, 10: decimal, and 16: hexadecimal. If someone doesn’t pass this argument, the default value would be used as 10. However, if the arg1 starts with ‘0x’ or ‘0X’ the radix will default to 16. Also, in the earlier versions of ES if arg1 started with ‘0’, for example, ‘0232’, the radix would default to 8.
So when it comes to interpreting the parseInt() method, there are multiple rules in place, and we can see that the rules also depend upon the version of the ES one might be using. If we are not worried about ‘0x’ getting parsed as a hexadecimal number then surely we can ignore the rule in the NodeJS backend, as we would not be using that old version of ES. But we can not ignore it in frontend, because we wouldn’t know what version the client would be using.
Conclusion:
This post is not complete yet. The analysis is still ongoing, and therefore in the near future, a list of the rules will be presented here, which might have different configurations in nodeJS backend than that in the ReactJS frontend.
Thanks!
