Skip to content

Latest commit

 

History

History
60 lines (43 loc) · 3.31 KB

2017-11-09.md

File metadata and controls

60 lines (43 loc) · 3.31 KB

09-Nov-2017 ESLint TSC Meeting Notes

Transcript

https://gitter.im/eslint/tsc-meetings/archives/2017/11/09

Attending

  • Teddy Katz (@not-an-aardvark) - TSC
  • Brandon Mills (@btmills) - TSC
  • alberto (@alberto) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • Kai Cataldo (@kaicataldo) - TSC
  • Nicholas C. Zakas Singh (@nzakas) - TSC

Topics

Nominating @platinumazure to the TSC

  • @ilyavolodin nominates @platinumazure to join the TSC.
  • 👍 from @not-an-aardvark, @btmills, @mysticatea, @kaicataldo, @alberto.
  • @nzakas abstains.

Resolution: @platinumazure is invited to join the TSC.

Reevaluate decision to skip running rules when linting whitespace-only files

  • TSC Summary: This is a proposal to change ESLint's behavior when it encounters a file that only contains whitespace. Currently, ESLint ignores whitespace-only files by design. However, this design choice arguably makes things more confusing now due to some changes in ESLint, so this issue proposes removing the special case.
  • TSC Question: Should we remove the special case for whitespace-only files?
  • Original proposal by @not-an-aardvark.
  • Some rules make assumptions about the AST that empty input might invalidate.
  • Linting empty files isn't necessarily the point of ESLint.
  • A breaking change should have significant benefit for users.
  • Not sure how many rules would break if we made this change.

Resolution: @not-an-aardvark will get more data about potential breakage for the next meeting.

Add package.json format option for eslint --init

  • TSC Summary: This issue proposes adding an selection in eslint --init to make ESLint create an eslintConfig property in package.json.
  • TSC Question: Should we accept this issue?
  • Do we need to match indentation? An npm package already exists if so.
  • What happens if package.json doesn't exist?
  • Don't want to be in the business of generating package.json.
  • This is a nice-to-have, but nobody is strongly for it.
  • @alberto, @kaicataldo, @nzakas, @not-an-aardvark, @mysticatea in favor of not accepting the change.

Resolution: We will not accept this change.

Support block-comment version of eslint-disable-line

  • TSC Summary: This issue proposes allowing eslint-disable-line and eslint-disable-next-line directives in block comments. This would be convenient for JSX, and would allow some external code processors to add disable comments more easily.
  • TSC Question: Should we accept this proposal?
  • @nzakas wonders if we can come up with something that will be useful everywhere, not just JSX.
  • Some discussion of /* eslint-disable-next-statement */. @btmills feels this could cause more confusion than the existing workaround of wrapping in disable/enable block comments or the current proposal.
  • Ignore line directives inside block comments that span multiple lines. We can consider warning on these in a major release.
  • Merge multiple directives on the same line.
  • 👍 from @not-an-aardvark, @btmills, @alberto, @kaicataldo, @mysticatea

Resolution: The proposal is accepted under the above constraints.