Coding convention like Prettier and ESLint

[jinmayamashita]

The topic aims to engage in a discussion regarding the suitability of various coding conventions, such as Prettier and ESLint rules, within our projects.

The conditions for concluding the discussion are as follows: determining the rules, specifying who will create pull requests and until when.

[jinmayamashita]

Let's start with React/ESLint.

Here's a basic proposal with detailed file and handler function naming conventions, as well as React-specific rules.
However, if there are any missing or unnecessary items, please provide your feedback.

module.exports = {
  root: true,
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  settings: {
    react: {
      version: 'detect',
    },
  },
  ignorePatterns: ['dist', '.eslintrc.cjs', 'prettier.config.cjs'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:unicorn/recommended',
    'plugin:react/recommended',
    'plugin:react/jsx-runtime',
    'plugin:react-hooks/recommended',
  ],
  plugins: ['@typescript-eslint', 'react'],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: ['./tsconfig.json', './tsconfig.node.json'],
  },
  rules: {
    'no-console': 2,
    eqeqeq: 2,
  },
  overrides: [
    {
      files: ['**/*.{jsx,ts,tsx}'],
      rules: {
        'react/jsx-pascal-case': 2,
        '@typescript-eslint/naming-convention': [
          2,
          {
            selector: 'variable',
            format: ['camelCase', 'UPPER_CASE'],
          },
          {
            selector: 'variable',
            types: ['boolean'],
            format: ['PascalCase'],
            prefix: ['is', 'has', 'did', 'will', 'can', 'should'],
          },
          {
            selector: ['variable', 'function'],
            types: ['function'],
            format: ['camelCase', 'StrictPascalCase'],
          },
          {
            selector: ['interface', 'typeLike'],
            format: ['PascalCase'],
          },
        ],
        'react/jsx-handler-names': [
          2,
          {
            eventHandlerPrefix: 'handle',
            eventHandlerPropPrefix: 'on',
            checkLocalVariables: false,
            checkInlineFunction: false,
          },
        ],
        'react/jsx-filename-extension': [2, { extensions: ['.tsx'] }],
        'react/destructuring-assignment': [2, 'always'],
        'react/hook-use-state': [2, { allowDestructuredState: false }],
        'react/jsx-props-no-spreading': 2,
        'react/no-unstable-nested-components': 2,
        'react/prefer-stateless-function': 2,
        'react/jsx-no-useless-fragment': 2,
        'react/forbid-component-props': 2,
        'unicorn/prevent-abbreviations': [
          'error',
          {
            allowList: {
              Props: true,
            },
          },
        ],
      },
    },
  ],
};

[ptrkdan]

[MEMO]

'react/jsx-filename-extension': [2, { extensions: ['.tsx'] }],

This assumes that Typescript is used. There are currently no plans to support JS-only versions, so this rule only allows .tsx.

[ptrkdan]

It would be nice to have a compilation of explanations for each rule somewhere. Perhaps in the wiki?
From the perspective of a beginner developer, it may be overwhelming trying to understand what each rule does, so we could provide a link that they could check out if they become curious. (Even I had to check out what some of the rules are for 😵‍💫 )

Regarding the rules above, if we are to focus on providing "best coding practices", setting the rule severity to 2 (error) would be understandable. However, it may become frustrating to more experienced developers.

What do other people think? I feel like more experienced developers would customize the configuration after generating the project so it would be alright to leave the rule severity to 2, but is it too extreme?

[mvn-huynguyen-hn]

can you create a PR for this part then other developers can give their comments?

[jinmayamashita]

@mvn-huynguyen-hn FYI @ptrkdan

can you create a PR for this part then other developers can give their comments?

I've created the PR. Let's continue discussing the finer details of the rules. (Please also inform other members from Vietnam. 🙏🏻)

#1208

[mvn-tiennguyen-hn]

@ptrkdan @jinmayamashita I think we can take a look at Biome. In all-in-one toolchain trending, it is a tool that is so good about both DX and performance. With Biome, we can simply run biome format app.tsx to format and biome lint app.tsx to lint. One configuration file, one document, and one tool. Beside its own rules, Biome also supported some many eslint rules but not at all. It will support more rule in next versions. As I see, this tool will free a lot of time to learn syntax for each tool in project. However, the trade-off is that the community is not really big and the customization is not easy as eslint.

Benchmark

Below is benchmark result for formatting and linting task. You can see details here

Formatting

• Biome's ~25 times faster than Prettier
• Biome's ~20 times faster than parallel-prettier
• Biome's ~20 times faster than xargs -P1
• Biome's 1.5-2 times faster than dprint
• Biome single-threaded is ~7 times faster than Prettier.

Linting

• Biome's ~15x times faster than ESLint
• Biome single-threaded is ~4 times faster than ESLint.

[jinmayamashita]

@mvn-tiennguyen-hn FYI @ptrkdan
Thank you for the introduction! Biome sounds great. It's my first time hearing about it.

Biome is a really fresh tool. They have only released version 1.0.0 and it's been less than a year. Although its history is much shorter compared to the eslint/prettier empire, I think their overwhelming performance (probably made with Rust) and the active community are strengths.

Here are some things I liked after trying out Biome:

• Firstly, the concise documentation is easy to understand.
• It's helpful to have a VSCode extension (there's also one for Helix ❤️).
• Most rules related to React that require separate packages in eslint are mostly built-in here.
• The CLI commands are also extensive (small detail, but the ci command is refreshing).
• It also supports automatic import sorting, which is convenient.

The config was easier than I expected.

{
  "$schema": "https://biomejs.dev/schemas/1.5.3/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 80,
    "lineEnding": "lf",
    "ignore": []
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "nursery": {
        "useFilenamingConvention": {
          "level": "error",
          "options": {
            "filenameCases": ["kebab-case"]
          }
        }
      },
      "style": {
        "useBlockStatements": "error",
        "useShorthandArrayType": "error",
        "noShoutyConstants": "warn"
      }
    }
  }
}

However, there are a few minor complaints:

• Is there still no jsx-handler-names yet?
• Regarding filenaming-convention: Although it's a small issue, I wonder if the following rules can be applied to files other than JSX/JS (json, css, html). I couldn't get it to work properly (whether it's a configuration issue or not).
  Here is the link for reference.

🤔 💭

First, let's solidify the rules for eslint/prettier and then see how well Biome can cover them. If it can cover the important rules, transitioning should not be a problem. 👍🏻

[ptrkdan]

It's the first time for me to hear about Biome, as well. It looks very promising! Perhaps we could implement it as an ESLint alternative?
Since ESLint and Prettier are still very dominant in the market, and most developers are familiar with it, they may be more comfortable using them when starting a new project. Adding Biome as an alternative formatting/linting module could be a way to challenge our templating strategy!

[mvn-tiennguyen-hn]

@ptrkdan Yes. A public template should use the most popular tools on the market. Using a tool that is relatively new and has not yet a certain impact on the community can affect the company's reputation. However, from the perspective of an independent developer, I will definitely still choose Biome 😁

[mvn-tiennguyen-hn]

Maybe I'll open a separate branch using Biome for internal experimental