How I Write Beautiful Code in VCF Operations Orchestrator using ESLint and Prettier

When developing code for VCF Operations Orchestrator, I follow a strict and consistent style methodology. This approach significantly simplifies navigating multiple files, identifying patterns, and maintaining readability across the codebase.

Adhering to both industry-standard and custom styling conventions can be tedious, but fortunately, some tools make this process much simpler once properly configured. These tools help automate formatting and ensure consistency across the codebase with minimal manual effort.

I use two different tools to achieve this:

• ESLint – A widely used linting tool for JavaScript and TypeScript that helps identify and fix problems in your code. It supports customizable rules and can automatically apply fixes, making it a powerful tool for maintaining code quality and consistency.
• Prettier – A code formatting tool that enforces consistent stylistic rules across your codebase. Unlike ESLint, Prettier doesn’t check for logical errors or implement best practices. While ESLint can also handle formatting, Prettier is increasingly favoured for this purpose due to its “zero-config” simplicity, speed, and consistent output.

Here are just a few examples of the types of issues these tools can detect:

• Missing JSDoc blocks for functions and classes
• Incorrect or inconsistent indentation
• Lines exceeding the maximum allowed length
• Use of single quotes instead of preferred double quotes
• Multiple consecutive empty lines
• Missing spaces around unary operators

While some of these rules may seem opinionated, the configuration is highly customizable to suit your preferences or team standards. That said, it’s worth noting that Prettier is intentionally opinionated, by design, to promote consistency with minimal configuration.

What makes these tools even more powerful is their ability to fix syntax and styling issues automatically; No need to chase down red squiggly lines or manually correct formatting. With proper configuration, they can automatically apply fixes every time you save a file, allowing you to stay focused on writing code while ensuring consistency and clean formatting in the background.

Below is an example of some of the style fixes that can be detected and fixed:

In the screenshot above, there are three identified issues:

1. The first if statement does not use strict inequality (!==).
2. There is no newline between the second and third if statements.
3. There are two consecutive newlines following the third if statement.

When the file is saved, these issues are automatically corrected by the configured tooling, ensuring clean, consistent code with no manual intervention.

The screenshots above demonstrate this functionality in Visual Studio Code (I’ll walk through how to set this up later in the post), but the same results can be achieved via the command line, making it easy to integrate into a CI pipeline or use in environments without an IDE.

Configure Development Environment for ESLint and Prettier

The following steps assume that your source code is available locally on your workstation. This also assumes you’re using the Build Tools for VMware Aria, which enable you to manage your Orchestrator code in a local development environment. Additionally, you’ll need Node.js installed, though this should already be available if you’re working with the Build Tools. I should also note that I am using Windows.

Open a command prompt and enter into the top-level directory of your project. Run the following command to install all the dependencies that are required for ESLint and Prettier to function.

npm install --save-dev eslint prettier jsdoc @eslint/js eslint-config-prettier eslint-plugin-prettier eslint-plugin-jsdoc

Both ESLint and Prettier require configuration files to define their rules and behavior. For ESLint, you’ll need an eslint.config.js file, and for Prettier, a .prettierrc file. These should be placed in the root directory of your project. To help you get started, I’ve linked to the configuration files from my own project as examples.

Once the dependencies are installed and configuration is in place, you can run each tool directly from the command line. It’s important to note that both ESLint and Prettier support two modes of operation: a check mode, which reports issues without making changes, and a write mode, which automatically applies fixes to the code.

# ESLint
## Check Mode
npx eslint "src\main\resources\**\*.js"

## Write Mode
npx eslint "src\main\resources\**\*.js" --fix


# Prettier
## Check Mode
npx prettier --check "src\main\resources/**/*.js"

# Write Mode
npx prettier --write "src\main\resources/**/*.js"

In check mode, Prettier will simply warn which file is non-compliant.

Whereas ESLint will do the same, but will go into a bit more detail, highlighting the exact line number where a rule was broken and specifying which rule was violated.

It’s important to note that while Prettier is specifically designed to handle code formatting, ESLint also includes rules for styling. This overlap can lead to both tools attempting to fix the same issues, potentially causing conflicts or unnecessary performance overhead. To avoid this, Prettier can be integrated with ESLint by disabling any conflicting rules within the ESLint configuration. The configuration examples I’ve provided above already include this integration.

Using ESLint and Prettier with Visual Studio Code

If you are using Visual Studio Code as your preferred IDE then extensions are available for ESLint and Prettier. Search the extensions marketplace for “ESLint” and “Prettier – Code formatter“.

Edit your VSCode user or workspace settings and apply the following:

{
    // Use the new ESLint flat config style
    "eslint.useFlatConfig": true,

    // Only format when you have a Prettier config in your project:
    "prettier.requireConfig": true,

    // Use Prettier for all supported languages:
    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
}

The configuration above still requires you to manually format files with Prettier or rely on red squiggly lines to identify issues flagged by ESLint. If you’d prefer a fully automated experience, where formatting, styling, and syntax issues are resolved on save, you can enable this by adding the following additional configuration.

    // Format on save:
    "editor.formatOnSave": true,

    // use ESLint to fix issues (including padding) on save:
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": "explicit"
    },

Prettier typically applies formatting almost instantly, but ESLint can occasionally be slower, especially on larger files or projects with complex rule sets. If you’re experiencing performance issues, ESLint provides a way to diagnose them. You can run the following command against a file to perform an ESLint performance test:

set TIMING=1&& npx eslint src\main\resources\somefile.js

A report similar to the following will be displayed:

I found that JSDoc-related rules tend to be relatively slow and, in most cases, cannot be automatically fixed. As a result, I chose to exclude them from on-save processing. Fortunately, Visual Studio Code provides an option to configure this behavior in the User or Workspace settings, allowing you to exclude specific rules from being run automatically.

  "eslint.options": {
    "overrideConfig": {
      "rules": {
        // disable the slow rules in the editor on save
        "jsdoc/check-access": "off",
        "jsdoc/check-values": "off",
        "jsdoc/require-description": "off",
        "jsdoc/valid-types": "off",
        "jsdoc/no-undefined-types": "off",
        "jsdoc/check-alignment": "off",
        "jsdoc/check-param-names": "off",
        "jsdoc/check-tag-names": "off",
        "jsdoc/check-types": "off",
        "jsdoc/check-property-names": "off",
        "jsdoc/require-property-description": "off",
        "jsdoc/require-jsdoc": "off",
      }
    }
  },

I hope this post has provided useful insight into writing clean, consistent code for VCF Operations Orchestrator (or any JavaScript project). By automating formatting and enforcing industry-standard styles, you can maintain high-quality code without disrupting your primary focus: getting the job done efficiently.

If you use other styling tools, techniques, or have suggestions to improve my configuration, I’d love to connect and collaborate, feel free to share your ideas!