Static Code Analysis on a Monorepo — NodeJS + React

2 min readOct 31, 2019

Monorepo is a (good|bad) strategy? To be honest, I don’t care. But I realized I often use it when I’m developing NodeJS+React projects.

There are always two main concerns when I perform automatic Static Code Analysis on a monorepo: coverage and code patterns.

Regarding Coverage, the answer is pretty easy: Codacy allows partial reports for both backend and frontend. It’s documented here and goes a bit like this:

➜  ~ codacy-coverage-reporter report -l javascript -r server_report.xml --partial➜  ~ codacy-coverage-reporter report -l javascript -r client_report.xml --partial➜  ~ codacy-coverage-reporter final

In the Code Patterns chapter, it will always depend on the linter. ESLint is the de facto linting utility for JavaScript and since it has tons of useful plugins (yes, also for security), it’s what I’m using. By itself, it doesn’t solve my issue with having two different projects in the same repository. Fortunately, there’s a way:

In the src folder of my project, I usually create a client and a server folder. And here is where it makes sense to have the .eslintrs.js file. In this file, common rules can be set or even left empty

[repo]/src/.eslintrc.js
module.exports = {
 
}

Then inside each client or server folder, an additional .eslintrc.js, extending the src one, file can be added, overriding the rules defined previously.

[repo]/src/client/.eslintrc.js
module.exports = {
    "extends": "../.eslintrc.js",
    rules: {
        quotes: [2, "single"]
    }
}[repo]/src/server/.eslintrc.js
module.exports = {
    "extends": "../.eslintrc.js",
    rules: {
        quotes: [2, "double"]
    }
}

Locally seems to be going as expected. Now, to Codacy! Under the “Code Patterns” tab, I chose “Configuration File” instead of the Rules from the UI.

And got exactly the same, and expected, results.

Monorepo strategy may be debatable but will never be a problem.

Static Code Analysis on a Monorepo — NodeJS + React

Written by Hélio Rocha