Learn from the Code Infrastructure

For the last release, I was looking into the Mozilla GitHub repo and hoping to find some bugs to fix. Since most projects in Mozilla are split into small components, therefore, there are relatively a lot more miscellaneous bugs compared to the centralized VSCode and Brave project repo.

As for my growth goals, I want to take this chance to learn from the infrastructure and development cycle of the open source project.


The first bug I was working on is to add CSS lint support to the Blurts Server‘s infrastructure. Blurts Server is a node.js prototyping project for Mozilla Breach Alert feature. The fixing went straightforward since the issue page already gives out the solution. All I need is to read through the stylelint repo and understand the basic usage and apply it to the project.

Basically, the package.json is the core when working with node.js, since we not only use it to include dependencies but to define behaviors. Not surprisingly, many of the js libraries are able to work together, which makes the infrastructure changes a lot easier without extra modification.

For example, we just need to insert line #7 in the “scripts” section to enable “npm run lint” command to trigger our stylelint check. And we could customize our CSS checking rules by simply adding the “.stylelintrc” file.


{
"dependencies": {
},
"scripts": {
"lint": "npm-run-all lint:*",
"lint:js": "eslint .",
"lint:css": "stylelint –fix 'public/css/**/*.css'",
"lint:nsp": "nsp check",
"pretest": "npm run lint"
}
}

view raw

package.json

hosted with ❤ by GitHub


The second one is to remove unused references from the Kitsune, which is a Django application. I haven’t done any Python before, but I didn’t find it so hard to perform a clean-up.

By running the “git grep” command with -il options, I can easily identify where the references are used.

$ git grep -il 'treejack'
kitsune/products/jinja2/products/product.html
kitsune/sumo/migrations/0002_initial_data.py

What really interests me is the “product.html“, unlike normal HTML, they use {%...%} as open/close tag. After research, I figured out the “jinja” in the file path is actually a template engine for Python. And the {%...%} blocks represent the control structures, for instance, for loop and if…else statement.


The last issue I encountered is similar to the second one – do a bit of clean-up, while the topic is about logging in JavaScript.

What I have learned:

As part of the development, a project may need to utilize a various set of tools and libraries to fulfill testing purposes or doing some proofs-of-concept, but as the project progresses, constant monitoring and code maintenance is inevitable.

Learning how to set up and categorize the infrastructure is as important as implementing new features since it certainly provides convenience to maintain code health and adding further supports.