Skip to content

Latest commit

 

History

History
85 lines (51 loc) · 4.4 KB

2016-07-07.md

File metadata and controls

85 lines (51 loc) · 4.4 KB
Raw

07-Jul-2016 ESLint TSC Meeting Notes

Transcript

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

Attending

  • Nicholas Zakas (@nzakas) - TSC
  • Ilya Volodin (@ilyavolodin) - TSC
  • Brandon Mills (@btmills) - TSC
  • Gyandeep Singh (@gyandeeps) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • Alberto Rodríguez (@alberto) - TSC

Topics

eslint/eslint#6586

  • Proposal to rename no-native-assign to no-global-assign morphed into a core enhancement request for a way to alias rules.
  • Concerns over complexity of implementing an aliasing system vs. just copying the old rule into a new file with a new name.
  • What if both no-native-assign and no-global-assign are configured at the same time? Which would take precedence?

Resolution:

  1. Aliasing introduces too much complexity for the number of use cases we have, so we will not be doing aliasing.
  2. We will rename no-native-assign to no-global-assign. no-native-assign will be deprecated and subject to the rule deprecation policy to avoid a breaking change.

eslint/eslint#6190

  • Linting unnecessarily disabled comments has been requested a couple of times.
  • Disagreement if this functionality is best in the core or best as a standalone tool.
  • It seems like the best user experience would be to have it in core, so warnings could show up inside of editors. That can't be done with a separate tool.

Resolution: We will withhold acceptance until a prototype is available and can be evaluated for overall impact to the project. There is still concern over the amount of changes necessary to support this, so getting a prototype together will give us the data we need to decide.

eslint/eslint#5968

  • We've had the same request to disable ES6-specific rules when running in ES5 mode even if they are configured as an error or warning.
  • Doesn't seem right to couple rules to ecmaVersion.
  • Shareable config packages tend to create multiple configs so they can have one for ES5, one for ES6, etc.

Resolution: We will not update rules to check ecmaVersion before running.

eslint/eslint#5891

  • Proposal to add require-jsdoc option to allow just one JSDoc comment per accessor property pairs in classes (which is what JSDoc recommends).

Resolution: Approved for inclusion.

eslint/eslint#4345

  • We've always had a difficult relationship with configuration comments. Are they treated like regular comments in rules or not?
  • In some cases, we want rules to ignore configuration comments, but in other cases it seems like we want them included.
  • This issue evolved into a proposal for just not including configuration comments in any rules, but the implementation got tricky. If you omit configuration comments completely, they end up looking like blank lines/spaces in the code, which could trigger other rules.

Resolution:

  1. We do not want to strip configuration comments automatically.
  2. We do want to support skipping configuration comments in rules.
  3. We will only add this to rules when asked and will use @mysticatea's approach in eslint/eslint#6077 of specifying ignorePattern as an option.
  4. We will accept the issue as an enhancement request for lines-around-comment to add an ignorePattern option.

JSCS team involvement

There is less participation than I anticipated from the JSCS folks. Should we talk to see if there is an underlying issue there?

  • There's really just a bunch of coincidences that have kept the JSCS folks busy.
  • We aren't doing anything to make them feel unwelcome, it's just life getting in the way.

Resolution: Nothing big to address here. Nicholas to follow up with Marat and Alexej to double-check on where they're at.

Merging Pull Requests

It seems like I'm doing most of the merging, and I'd like to understand why that is.

  • Nicholas seems to be merging most of the pull requests, and it would be good to have more people merging more frequently.
  • People lack confidence in their ability to fully understand the code in PRs and don't feel comfortable merging them.
  • More automated testing would increase confidence.

Resolution: Nicholas to contact jQuery Foundation to get a Jenkins VM. Everyone to leave comment next to "LGTM" if they don't merge the pull request. Everyone to pick one day a week and review as many open PRs as possible.