Preset of lint used in JavaScript Projects #49

Activity

1. Keith-CY

   added

   Important

   Not Urgent

   on May 10, 2023
2. yanguoyu commented on May 11, 2023

   

   yanguoyu

   on May 11, 2023

   Last edited by yanguoyu

   More actions

   1. prettier https://prettier.io/docs/en/options.html

   {
     printWidth: 120,
     // Specify the number of spaces per indentation-level.
     tabWidth: 2,
    // Indent lines with tabs instead of spaces.
     useTabs: true,
    // Only add semicolons at the beginning of lines that [may introduce ASI failures](https://prettier.io/docs/en/rationale.html#semicolons).
     semi: false,
    // Use single quotes instead of double quotes.
     singleQuote: true,
    // Trailing commas where valid in ES5 (objects, arrays, etc.). No trailing commas in type parameters in TypeScript.
     trailingComma: 'es5',
    // Print spaces between brackets in object literals. 👍 { foo: bar } 👎 {foo: bar}
    bracketSpacing: true,
     👍/**
       <button
         onClick={this.handleClick}
       >
         Click Here
       </button>
     */
    👎
       <button
         onClick={this.handleClick}>
         Click Here
       </button>
     */
    bracketSameLine: false,
    // 👍 x => x   👎 (x) => x
    arrowParens: false,
    endOfLine: 'lf'
   }

   2. eslint https://eslint.org/docs/latest/rules/
      Eslint rules are so many so we can extend other rules and change some if we need.

   • no-multi-spaces: error Added by fix: update dependency jest when to v3 nervosnetwork/neuron#2684

   3. style-lint https://stylelint.io/user-guide/rules
      We can use its recommend rules https://www.npmjs.com/package/stylelint-config-recommended and change some if we need.
   4. commit-lint https://commitlint.js.org/#/

   import type {UserConfig} from '@commitlint/types';
   import { RuleConfigSeverity } from "@commitlint/types";
   
   const Configuration: UserConfig = {
     /*
      * Resolve and load @commitlint/config-conventional from node_modules.
      * Referenced packages must be installed https://commitlint.js.org/#/reference-rules
      */
     extends: ['@commitlint/config-conventional'],
     /*
      * Resolve and load @commitlint/format from node_modules.
      * Referenced package must be installed
      */
     formatter: '@commitlint/format',
     /*
      * Whether commitlint uses the default ignore rules.
      */
     defaultIgnores: true,
     /*
      * Custom URL to show upon failure
      */
     helpUrl: 'https://github.com/conventional-changelog/commitlint/#what-is-commitlint',
   };
   
   module.exports = Configuration;
3. WhiteMinds commented on May 17, 2023

   

   WhiteMinds

   on May 17, 2023

   More actions

   We can establish a repository to implement packages like @magickbase/tools and place common configuration files such as prettierrc.js, eslintrc.js inside it. Then, these configurations can be imported into the projects that need to use them, similar to the following example:

   // .prettierrc.js
   module.exports = {
     ...require('@magickbase/tools/prettierrc'),
     // other config
   }

   Reaching a consensus on a good solution may take a long time and involve significant differences of opinion. Therefore, we can start by incorporating the rules on which there is no disagreement into this repository and put them into practical use. This approach may facilitate the overall standardization and subsequent rule improvements.

   // 👍 x => x 👎 (x) => x
   arrowParens: false,

   I used to think the same way, but after referring to the explanation in https://prettier.io/docs/en/options.html#arrow-function-parentheses, I believe setting it to the default value 'always' might be better. Here's the quote:

   At first glance, avoiding parentheses may look like a better choice because of less visual noise. However, when Prettier removes parentheses, it becomes harder to add type annotations, extra arguments or default values as well as making other changes. Consistent use of parentheses provides a better developer experience when editing real codebases, which justifies the default value for the option.

   👍React with 👍1Reacted by 布偶什么的就是布偶
4. yanguoyu commented on May 24, 2023

   

   yanguoyu

   on May 24, 2023

   More actions

   IMO, Type Inference is a good feature with typescript.
   Should we set explicit-function-return-type error or warning? @Magickbase/developers
   Magickbase/neuron-public-issues#140 (comment)
5. WhiteMinds commented on May 31, 2023

   

   WhiteMinds

   on May 31, 2023

   More actions

   IMO, Type Inference is a good feature with typescript. Should we set explicit-function-return-type error or warning? @Magickbase/developers Magickbase/neuron-public-issues#140 (comment)

   I lean towards setting it to 'error'. Explicitly setting the return value allows for more effective type checking and makes the return value of the function easier for code readers to understand.
6. Keith-CY commented on Jun 4, 2023

   

   Keith-CY

   on Jun 4, 2023

   MemberAuthor

   More actions

   IMO, Type Inference is a good feature with typescript. Should we set explicit-function-return-type error or warning? @Magickbase/developers Magickbase/neuron-public-issues#140 (comment)

   I lean towards setting it to 'error'. Explicitly setting the return value allows for more effective type checking and makes the return value of the function easier for code readers to understand.

   My personal thought is to set external interfaces typed explicitly while leaving the internal ones inferred, it guarantees typesafe to users while keeping the flexibility of JavaScript.
7. Keith-CY commented on Jul 17, 2023

   

   Keith-CY

   on Jul 17, 2023

   MemberAuthor

   More actions

   I'll collect prettier/eslint configurations from our projects here, and deduplicate them.

   Once the checklist is ready, we can keep those controversial rules intact and expose the unanimous in the tools repo.