Local Dev Environment and Static Code Analysis

For this week, I decided to improve the developer-friendliness nature of my project, DialectMorph. I took on the responsibility to automate the various setup procedures that a developer needs to get the project running locally on their machine,I will now elaborate the use-case of each of them in this blog

Code Formatting

Given that my codebase is open-sourced, a lot of developers might contribute to it. This sometimes leads to the having inconsistent code-formatting, which might not be a good thing when it comes to providing a clean and smooth developer experience

So for this, I utilized Prettier, which is a library used to support the task of formatting

Overview

This tool is used to specify the formatting options which would remain consistent throughout the codebase,
All of the configuration settings for the same go into a config file called .prettierrc or any other supported file formats the tool provides which can be found in the documentation.

For my codebase, I have applied the following settings which would be tailored to my project

File-Name: .prettierrc

{
    "trailingComma": "es5",
    "semi": true,
    "tabWidth": 2,
    "printWidth": 80,
    "useTabs": true
}

the options here provide me with the following functionality
having trailing commas whenever it is included near the es5 syntax
semicolons at the end of every statement
Sets the number of spaces per indentation level to 2
Limits line length to 80 characters.
It uses tabs for indentation instead of spaces

Now I would also want to ignore certain files or certain code blocks to not be formatted, for that use-case I have two options that is

• Using a file called .prettierignore to include all the files that I want to ignore
• I can also place the statement called prettier-ignore before the code blocks I don't want to be formatted

My initial formatting with prettier changed about 500 lines in my codebase

I have configured the following scripts in my package.json to have ease-of-use to call this tool

        "format": "bunx prettier . --write",
        "format:check": "bunx prettier . --check",

Linting

Linting is one of the common practices used in codebases to ensure the code is more consistent and to identify patterns that could lead to potential bugs

For my project, I utilized the tool called ESLint since it is compatible with typescript based projects

Overview

I used this tool to make sure that there was no errors or unused variables in my projects, also I had a couple of configuration settings as well

import globals from "globals";
import tseslint from "@typescript-eslint/eslint-plugin";
import tseslintParser from "@typescript-eslint/parser";

export default [
    {
        files: ["**/*.{js,mjs,cjs,ts}"],
        languageOptions: {
            globals: {
                ...globals.browser,
            },
            parser: tseslintParser,
            parserOptions: {
                ecmaVersion: "latest",
                sourceType: "module",
            },
        },
        plugins: {
            "@typescript-eslint": tseslint,
        },
        rules: {
            ...tseslint.configs.recommended.rules,
        },
    },
    {
        files: ["dist/**/*.js"],
        rules: {
            "@typescript-eslint/no-unused-expressions": "off",
            "@typescript-eslint/no-require-imports": "off",
        },
    },
    {
        files: ["examples/**/*.js"],
        rules: {
            "@typescript-eslint/no-unused-expressions": "off",
            "@typescript-eslint/no-require-imports": "off",
            "@typescript-eslint/no-unused-vars": "off",
        },
    },
    {
        files: ["src/index.ts"],
        rules: {
            "@typescript-eslint/no-explicit-any": "off",
        },
    },
];

This configuration file manages linting rules for my project through multiple configuration blocks. The primary block sets up basic TypeScript linting for all code files with browser globals and recommended rules, while subsequent blocks relax specific rules for distribution files and examples. Finally, it includes a special configuration for src/index.ts that allows the use of the any type.

I have configured the following scripts in my package.json to have ease-of-use to call this tool

"lint": "bun eslint .",

Local Dev Environment

I wanted to make sure that the developer that is working on my repository has a smooth experience while setting up my repository.

I have been working on my codebase in VSCode mostly, so I decided to include a .vscode folder which would allow me to specify the necessary things needed for a smooth experience

extensions.json file

This file contains the name of all the extensions that would provide a better experience to the developer while they are working on my repository, when the users open ups my repository for the first time,
they will see the prompt to install the recommended extensions, for my program you can see the recommended extensions as follows

{
    "recommendations": [
        "dbaeumer.vscode-eslint", // ESLint support
        "esbenp.prettier-vscode", // Prettier formatting
        "ms-vscode.vscode-typescript-next", // TypeScript support
        "aaron-bond.better-comments", // Better code comments
        "christian-kohler.path-intellisense", // Path autocompletion
        "streetsidesoftware.code-spell-checker", // Spell checking
        "eamodio.gitlens", // Git integration
        "yoavbls.pretty-ts-errors", // Better TypeScript errors
        "wayou.vscode-todo-highlight", // Highlight TODOs
        "gruntfuggly.todo-tree" // Track TODOs
    ]
}

`settings.json' file

The file contains all the editor settings for VSCode, that again is not necessarily needed but is again used for a great and seamless experience for the developer. I believe if you want people to work on your codebase, automate the manual setup things and provide them with a great experience.

This settings.json file is particularly used for specifying the setting for VSCode editor and environment

I have provided the following settings for the same

`
// arbitary settings for vs code to have good config settings

{
"window.zoomLevel": 0.5,
"workbench.tree.indent": 20,
"editor.minimap.renderCharacters": false,
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
"editor.cursorBlinking": "smooth",
"files.eol": "\n",
"files.trimTrailingWhitespace": true,

"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,

"prettier.trailingComma": "es5",
"prettier.semi": true,
"prettier.tabWidth": 2,
"prettier.useTabs": true,
"prettier.printWidth": 80,

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": "always"
},
"eslint.validate": ["typescript"]

}

`

Git Hooks (Pre-Commit)

Git-Hooks are scripts that automatically run at a specified timeline in the git execution pipeline, they are triggered at different events like having a pre-commit hook, a post-commit hook. They are really useful to perform additional sanity testing task or basic cleaning tasks before the data is pushed or committed

For my use-case I have only utilised pre-commit hook as I didn't see the use of having other hooks right now in my project

To implement these hooks I have utilised another library called husky

How this works is you can specify the type of git events you want and what command should run when the git event occurs,for my package.json I have the following settings

`sh

"husky": {
    "hooks": {
        "pre-commit": "bun run format"
    }
},

`

the above command specifies that there is only a pre-commit event that would run the command to format my entire code before committing it.

This is by far one of the best things I have come across recently.

Conclusion

Through the implementation of tools like Prettier, ESLint, VSCode configurations, and Git hooks, I've significantly reduced the manual setup burden for potential contributors. These improvements not only make the codebase more maintainable but also create a welcoming environment for developers who might want to contribute to the project in the future.