Skip to content

Latest commit

 

History

History
85 lines (56 loc) · 5.35 KB

2018-08-02.md

File metadata and controls

85 lines (56 loc) · 5.35 KB

2018-August-02 ESLint TSC Meeting Notes

Transcript

https://gitter.im/eslint/tsc-meetings/archives/2018/08/02

Attending

  • Brandon Mills (@btmills) - TSC
  • Ilya Volodin (@ilyavolodin) - TSC
  • Kevin Partington (@platinumazure) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • Kai Cataldo (@kaicataldo) - TSC
  • Teddy Katz (@not-an-aardvark) - TSC

Topics

Fix: parsing YAML .eslintrc with JS-like comments

TSC Summary: The purpose of this PR is to support JS comments in a YAML-formatted .eslintrc (not .eslintrc.yml or .eslintrc.yaml). Some questions were raised about the implementation, and after some discussion, other questions were raised about whether this is something we should support given that the .eslintrc format is deprecated and we support JS comments in both .eslintrc.json (using strip-json-comments to remove JS comments) and .eslintrc.js. JS-style comments have been supported in .eslintrc for a long time. The current implementation breaks some valid YAML. The question is whether to fix it (and how), whether to provide a better error message, or whether to leave it as-is.

TSC Question: Should we support JS comments in YAML-formatted .eslintrc file without extension?

  • General reluctance to altering the behavior of a deprecated feature when other config formats are available.
  • If somebody wanted a better error message, that would be okay.
  • 👎 to functional changes from @platinumazure, @mysticatea, @btmills, @ilyavolodin, @kaicataldo
  • 👍 to better error message from @ilyavolodin, @platinumazure, @kaicataldo, @mysticatea, @btmills

Resolution: No functional changes should be made, but a better error message would be great.

Warning for ignored files on linting

TSC Summary: This issue proposes adding a command-line flag to disable "this file is ignored" warnings for ignored files, and instead simply report no errors when a path to an ignored file is provided. This would be useful for integrations (many integrations currently get around this problem by manually filtering out reports that match the "this file is ignored" message).

TSC Question: Should we accept this proposal?

  • This discussion began in the previous meeting. Since then, @btmills posted a script to take solve this use case using the isPathIgnored API. @not-an-aardvark is of the opinion that this functionality should be available on the CLI.
  • @btmills and @ilyavolodin feel there are too many CLI flags already and are reluctant to add more.
  • Philosophically, should the CLI support integrations, or is CLIEngine the preferred route there?
  • Symmetry between CLIEngine and the CLI would be nice, but @btmills and @ilyavolodin believe we wouldn't have added the warnIgnored option to CLIEngine today, so does symmetry justify extending an API some would rather deprecate?

Resolution: We won't add this feature.

do not ignore files started with . by default

TSC Summary: eslint ingore .* by default -- it can cause confusing to users. so I am proposing: do not ignore file/dir beginning with a dot by default, except . and ..

TSC Question:

  1. Should we accept this change?
  2. Should .git, .hg, .svn be ignored by default?
  • In addition to .eslintrc.js and .babelrc.js, VuePress has code in a dot-prefixed directory. There are lots of different use cases.
  • Can we lint dot-prefixed files but ignore dot-prefixed directories? That avoids having to hard code an exception for .git/.
  • If we lint dot-files, how do we decide on a list of exceptions?
  • Since there are so many use cases, and it'd be hard to choose a correct default that differes from the bash model, what if we improve the documentation with specific examples for a variety of different use cases?
  • If we improve the docs, we can put this on hold to see if that change is sufficient. We'd have to wait for the next major release anyway if we were to change the default.
  • 👍 from @btmills, @not-an-aardvark, @kaicataldo, @platinumazure, @mysticatea

Resolution: Add examples to the docs and see if that is sufficient.

1tbs allows consecutive if statements

TSC Summary: This issue was reported as a bug. The complaint is that it is possible to do consecutive if statements in 1tbs brace-style. Arguably the intent of 1tbs is to only allow consecutive else if's, not consecutive ifs. Given how long the current behavior has been out there, I wonder if this should be considered a breaking change.

Consecutive ifs:

if (foo) {
    doSomething();
} if (bar) {
}

TSC Question: Should this be accepted as a bug, and if so, as a breaking change or non-breaking?

  • Since this is two different statements, it doesn't really fall under brace-style.
  • It could be handled by max-statements-per-line if configured to 1.
  • A new rule could do the job here, but probably not in core. It would be relatively straightforward to implement using selector syntax and checking locations.
  • 👎 to changing from @btmills, @not-an-aardvark, @mysticatea, @kaicataldo. @platinumazure defers to consensus.

Resolution: We won't alter brace-style to handle this case.

Scheduled release for August 3rd, 2018

To be figured out offline.