any-eslint-parser.github.io

Check Any file with ESLint

______

Quick Start

1 . Add dependencies:

package.json:

  ..
  "devDependencies": {
    "any-eslint-parser": "1.0.0",
    "eslint": "*",

2 . Configure eslint with the required rules, e.g. eol-last and no-tabs:

.eslintrc-any.json:

{
  "parser": "any-eslint-parser",
  "rules": {
    "eol-last": "error",
    "no-tabs": "error"
  }
}

Any eslint rule that not required AST can be used, this example uses eol-last and no-tabs.

3 . Configure linting script:

package.json:

  "scripts": {
    "lint.any": "eslint --config .eslintrc-any.json \"**/*.+(js|jsx|ts|tsx|json|yml|xml|sh|txt|md|svg|properties|gradle|java|cpp|c|html|css|groovy|gitignore|npmignore)\"",

---

Goals

any-eslint-parser provides a parser so “any” type of file can be checked by eslint. Although eslint claims to be AST-based, there are rules that does not based on AST, rather they are based on the text content of the file, e.g. eol-last, no-tabs, eslint-plugin-regex, etc. any-eslint-parser can be used to check json files, yaml files, script files, source code files in any programming language (e.g. java, c++, groovy, etc.), svg files, markdown files, etc.

This idea arise from the need to use eslint-plugin-regex in other type of files, besides javascript. (Then saw on this as a more versatile and configurable way to check common files than using lintspaces)

• Rules that required AST will simply be ignored, i.e. no error will be reported.
  • Neither the list of eslint rules, nor rules description provide explicit information on whether they need AST or not, so, You may need to test the rules before using, or use regex rules aka eslint-plugin-regex.
• Cascading and Hierarchy of ESlint Configuration files are still applied.
  • Remember if eslintrc-any.json or any parent have rules that require AST, those will be ignored when using any-eslint-parser.
  • You may want to use an independent .eslintrc.json file when using any-eslint-parser (take a look at Migrating to eslint/any-eslint-parser from lintspaces as detailed example).
    • Using --no-eslintrc option can be very helpful since will ignore all configuration files, i.e .eslintrc.* and package.json, only taking in account the one set with --config option.
    • May want to ignore some folders or files using --ignore-pattern or --ignore-path.
    • All these options --no-eslintrc, --ignore-pattern and --ignore-path are very useful when other parser are used in the project in order to avoid conflicts.

Examples

Replacing lintspaces

.eslintrc-any.json

  {
    "parser": "any-eslint-parser",
    "rules": {
      "eol-last": "error",
      "no-tabs": "error"
    }
  }

package.json:

  "scripts": {
    "lint.any": "eslint --config .eslintrc-any.json \"**/[\\.a-zA-Z]*.+(js|jsx|ts|tsx|json|yml|xml|sh|txt|md|svg|properties|gradle|java|cpp|c|html|css|groovy)\" \"**/.+(|gitignore|npmignore)\" --no-eslintrc --ignore-pattern \"build\""
  },
  "devDependencies": {
    "any-eslint-parser": "1.0.0",
    "eslint": "*"
  }

More detail at Migrating to eslint/any-eslint-parser from lintspaces.

Using eslint-plugin-regex

Requiring Copyright and License on every source file of a project.

.eslintrc-any.json

  {
    "plugins": ["regex"],
    "parser": "any-eslint-parser",
    "rules": {
      "regex/required": [
        "error", [
          "^(?:(?:\\/\\/)|#) Copyright \\(c\\) Super Team",
          "^(?:(?:\\/\\/)|#) Licensed under the MIT License \\(MIT\\), see LICENSE.txt"
        ]
      ]
    }
  }

package.json:

  "scripts": {
    "lint.any": "eslint --config .eslintrc-any.json \"**/*.+(js|jsx|ts|tsx|gradle|java|cpp|c|groovy|yml|sh)\""
  },
  "devDependencies": {
    "any-eslint-parser": "1.0.0",
    "eslint": "*",
    "eslint-plugin-regex": "*"
  }

More regex rules examples at eslint-plugin-regex and eslint-plugin-base-style-config regex rules.

---

Prerequisites

• "eslint": "*".

---

Contributing

• Use it.
• Share it.
• Give it a Star.
• Propose changes or improvements.
• Report bugs.

License

MIT License ______

Remember

• Use code style verification tools => Encourages Best Practices, Efficiency, Readability and Learnability.
• Code Review everything => Encourages Functional suitability, Performance Efficiency and Teamwork.
• If viable, Start testing early => Encourages Reliability and Maintainability.

Additional words

Don’t forget:

• Love what you do.
• Learn everyday.
• Learn yourself.
• Share your knowledge.
• Think different!.
• Learn from the past, dream on the future, live and enjoy the present to the max!.
• Enjoy and Value the Quest (It’s where you learn and grow).

At life:

• Let’s act, not complain.
• Be flexible.

At work:

• Let’s give solutions, not questions.
• Aim to simplicity not intellectualism.

This site is open source. Improve this page.