Skip to content

Latest commit

 

History

History
126 lines (85 loc) · 6.94 KB

README.md

File metadata and controls

126 lines (85 loc) · 6.94 KB
Raw
  • Start Date: 2019-05-12
  • RFC PR: (leave this empty, to be filled in later)
  • Authors: Toru Nagashima (@mysticatea)

The linterOptions property in Config Files

Summary

This RFC adds linterOptions property to config files. People can use config files (including shareable configs!) instead of CLI options in order to configure some linter behavior.

Motivation

We cannot configure some linter's behavior with config files, especially, shareable configs. It's convenient if we can configure those in shareable configs.

Detailed Design

This adds linterOptions property to config files with three properties.

// .eslintrc.js
module.exports = {
    linterOptions: {
        allowInlineConfig: true,              // Corresponds to --no-inline-config / `options.allowInlineConfig`
        reportUnusedDisableDirectives: "off", // Corresponds to --report-unused-disable-directives / `options.reportUnusedDisableDirectives`
        ignorePatterns: [],                   // Corresponds to --ignore-pattern / `options.ignorePattern`
    },

    overrides: [
        {
            files: ["*.ts"],
            linterOptions: {
                allowInlineConfig: true,
                reportUnusedDisableDirectives: "off",
                ignorePatterns: [],
            },
        },
    ],
}

Ajv should verify it by JSON Scheme and reject unknown properties in linterOptions.

allowInlineConfig

That value can be a boolean value. Default is true.

If false then it disables inline directive comments such as /*eslint-disable*/.

🚀 Implementation:

In Linter#_verifyWithoutProcessors method, the linter checks both providedConfig and filenameOrOptions to determine allowInlineConfig option. The filenameOrOptions.allowInlineConfig precedences providedConfig.allowInlineConfig.

reportUnusedDisableDirectives

That value can be one of "off", "warn", and "error". Default is "off".

It reports directive comments like // eslint-disable-line when no errors would have been reported on that line anyway.

  • If "warn" then it doesn't cause to change the exit code of ESLint.
  • If "error" then it causes to change the exit code of ESLint.
🚀 Implementation:
  1. Linter and CLIEngine have options.reportUnusedDisableDirectives. This RFC enhances these options to accept "off", "warn", and "error". Existing false is the same as "off" and existing true is the same as "error".
  2. In Linter#_verifyWithoutProcessors method, the linter checks both providedConfig and filenameOrOptions to determine reportUnusedDisableDirectives option. The filenameOrOptions.reportUnusedDisableDirectives precedences providedConfig.reportUnusedDisableDirectives.

ignorePatterns

That value can be an array of strings. Default is an empty array.

This is very similar to .eslintignore file. Each value is a file pattern as same as the line of .eslintignore file. ESLint compares the path to source code files and the file pattern then it ignores the file if it was matched. The path to source code files is addressed as relative to the entry config file, as same as files/excludedFiles properties.

Negative patterns mean unignoring. For example, !.*.js makes ESLint checking JavaScript files which start with .. This is worthful for shareable configs of some platforms. For example, the config of VuePress can provide the configuration that unignores .vuepress directory.

If this property is in overrides entries, ESLint checks only if files/excludedFiles criteria were matched.

🚀 Implementation:

At lib/cli-engine/file-enumerator.js#L402, the enumerator checks if the current path should be ignored or not. ESLint merges .eslintignore, --ignore-path, --ignore-pattern, and this ignorePatterns. The --no-ignore CLI option disables this setting.

Other options?

  • extensions - This RFC doesn't add extensions option that corresponds to --ext because #20 "Configuring Additional Lint Targets with .eslintrc" is the good successor of that.
  • rulePaths - This RFC doesn't add rulePaths option that corresponds to --rulesdir because #14 (localPlugins) is the good successor of that. Because the rulePaths doesn't have namespace, shareable configs should not be able to configure that. (Or but it may be useful for some plugins such as @typescript-eslint/eslint-plugin in order to replace core rules. I'd like to discuss the replacement way in another place.)
  • format - This RFC doesn't add format option that corresponds to --format because it doesn't fit cascading configs. It needs another mechanism.
  • maxWarnings - This RFC doesn't add maxWarnings option that corresponds to --max-warnings because it doesn't fit cascading configs. It needs another mechanism.

Documentation

Drawbacks

  • Nothing in particular.

Backwards Compatibility Analysis

  • No concerns. Currently, the linterOptions top-level property is a fatal error.

Alternatives

Open Questions

Frequently Asked Questions

Related Discussions