Skip to content

Latest commit

 

History

History
84 lines (64 loc) · 7.04 KB

2017-12-07.md

File metadata and controls

84 lines (64 loc) · 7.04 KB
Raw

07-Dec-2017 ESLint TSC Meeting Notes

Transcript

https://gitter.im/eslint/tsc-meetings/archives/2017/12/07

Attending

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

Topics

Proposal: Add URL for a rule's documentation to the API

  • TSC Summary: This proposal suggests adding docs.uri/docs.url to meta property of each built-in rule with the link to rule's documentation.
  • TSC Question: Do we accept this proposal?
  • Q: What happens when docs change between versions?
  • A: Versioned links could solve this. How important is that vs how hard is it to implement? Let's leave versioned docs out of this particular change. We can address that later if necessary.
  • Q: Do we need to expose rule metadata in CLIEngine? We don't want people to start using the undocumented cliEngine.linter.getRules() method.
  • A: Add a getRules() instance method to CLIEngine. Currently it will pass through to the method on the internal linter instance.
  • 👍 from @ilyavolodin, @not-an-aardvark, @mysticatea, @btmills, @kaicataldo, @alberto, @gyandeeps
  • 👍 from @platinumazure with reservations about whether CLIEngine is the best place to put it.

Resolution: Accept the proposal and add a new getRules instance method to CLIEngine.

Update: Improve parser integrations (fixes #8392)

  • TSC Summary
  • The purpose of this feature is that it makes people being possible to make custom parsers which can handle experimental/enhancement syntaxes without monkey patching.
  • This feature allows custom parsers return scopeManager and visitorKeys.
  • The scopeManager is a ScopeManager object. Custom parsers can use custom scope analysis for experimental/enhancement syntax (e.g. do expressions, decorators, type definitions, type references, ...). If a custom parser returns scopeManager, ESLint uses it. Otherwise, ESLint analyzes scope by using eslint-scope as same as current.
  • The visitorKeys is an object to customize AST traversing. If a custom parser returns visitorKeys, ESLint uses it in eslint-scope and traversing logic. Otherwise, KEYS of eslint-visitor-keys is used.
  • To tell custom parsers that ESLint supports scopeManager and visitorKeys, now parserOptions has eslintVisitorKeys:true and eslintScopeManager:true as similar to range:true and something like.
  • As a side effect, now SourceCode class has new properties parserServices, scopeManager, and visitorKeys. Because linter.verify accepts a SourceCode object as the first argument instead of text and skips parsing. SourceCode object must have all of the parsing result.
  • I confirmed that I can implement babel-eslint with this feature and without monkey patching: babel/babel-eslint#542
  • TSC Question: Should we accept this issue?
  • This will need plenty of documentation, preferably with examples.
  • 👍 from @not-an-aardvark, @ilyavolodin, @platinumazure, @kaicataldo, @btmills, @alberto, @mysticatea
  • @gyandeeps abstains.

Resolution: The proposal is accepted.

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?
  • @not-an-aardvark: When we discussed this last meeting, we postponed a decision so that we could gather more data about how many rules this would break. I collected some data and posted the results in eslint/eslint#9534 (comment) .
  • Q: eol-last is the only user-exposed rule that will fail with its default options on empty files. Should we add a special case?
  • A: eol-last's job is to make sure that the last line of content ends in a newline. Warning on empty files is unrelated, so we should add an exception.
  • Not all possible configs were tested in @not-an-aardvark's analysis. Look into ways to test more configs to find potential crashes. For example, strict in global mode will fail for empty files.
  • 👍 from @mysticatea, @alberto, @gyandeeps, @platinumazure, @not-an-aardvark, @btmills

Resolution: This proposal is accepted as a breaking change.

Should we rename "beginner" label to "good first issue"?

  • TSC Summary:
  • Per this article on GitHub Help, it seems that GitHub is flagging issues with the "help wanted" or "good first issue" label for new contributors.
  • We're already using "help wanted", and "beginner" seems semantically equivalent. So I'd like to propose changing the label from "beginner" to "good first issue" to take advantage. (Also, as a small side benefit, it avoids any risk that the "beginner" label could seem pejorative to someone who has experience coding but has not contributed to this repository before.)
  • TSC Question: Should we do this for the ESLint repo? Should we do this for other repos in the ESLint organization?
  • 👍 from @kaicataldo, @platinumazure, @btmills, @mysticatea, @not-an-aardvark, @alberto, @ilyavolodin, @gyandeeps

Resolution: We will rename the "beginner" label to "good first issue".

Transfarring eslint-cli to eslint organization

  • TSC Summary:
  • eslint-cli is the package which provides CLI command eslint which finds local-installed ESLint and runs it. I would like to transfer eslint-cli to eslint organization.
  • I think that eslint-cli improves eslint/eslint#6732 (comment) with updating "Getting started" page. This transferring would make peace of mind to users as the tool is supported by the eslint team.
  • I don't worry about copyrights because all commits of eslint-cli are mine and all dependencies are MIT license.
  • TSC Question: Do we accept this proposal?
  • @not-an-aardvark is concerted it could cause confusion that both eslint and eslint-cli are both runnable globally but behave differently.
  • This question has come up many times, and we still don't have a good answer. For now, tabling discussion about moving this functionality into core so we can discuss just moving the project into the organization.
  • Tabling discussion until the next meeting due to time.
  • @ilyavolodin has a proposal for this and will create a GitHub discussion for it.