Skip to content

Latest commit

 

History

History
60 lines (40 loc) · 3.73 KB

2016-10-13.md

File metadata and controls

60 lines (40 loc) · 3.73 KB

13-Oct-2016 ESLint TSC Meeting Notes

Transcript

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

Attending

  • Nicholas Zakas (@nzakas) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • alberto (@alberto) - TSC
  • Kai Cataldo (@kaicataldo) - TSC
  • Brandon Mills (@btmills) - TSC
  • Gyandeep Singh (@gyandeeps) - TSC
  • Ilya Volodin (@ilyavolodin) - TSC

Topics

Relaxing rules for who can merge PRs

  • I'd like to propose that we allow any team member to merge non-breaking PRs so long as at least one TSC member has approved the PR and the waiting period has passed.
  • If a TSC member has already approved a PR and is just waiting the 2-3 days for others to review, it doesn't really make sense to prevent committers from merging the PR after that point since the TSC member would likely have done it anyway. This could help ensure that PRs are landed faster because it expands the pool of people who can merge. Currently, committers cannot merge PRs other than chores, bug fixes, and documentation changes.
  • 👍 from @alberto, @kaicataldo, @btmills, @mysticatea

Resolution: Any team members can merge a PR provided that at least one TSC member has approved and the issue is past the waiting period. We will update the maintainer guide to reflect this resolution.

Review accepting pull requests without issues

  • Above agenda item ought to help with some of the backlog.
  • Having high level discussion of core changes in issues separate from technical discussion in PRs is working well.
  • The three checkbox for "I've read the contribution guidelines", "add docs", and "added tests" doesn't seem like it's helping anything.

Resolution: Those three checkboxes in the PR template will be changed to a comment.

ESLint fork of escope

  • I'd like to discuss creating an ESLint fork of escope. We've talked about this for a while behind-the-scenes, and I think it's time for us to make a decision.
  • Currently escope is not actively maintained, and it doesn't seem like asks for custom functionality are going to be accepted. Rather than continuing to fight about things we might need to support TypeScript or other functionality, I think it's time to consider forked escope for use within ESLint.
  • babel-eslint current reaches into the file system and monkey patches escope to support node types we don't know or understand. This would be a breaking change, as we'd have to give babel-eslint a heads up to avoid breaking those users.
  • 👍 from @gyandeeps, @mysticatea, @alberto, @kaicataldo

Resolution: Fork escope and work with babel-eslint to include the fork in v4.0.0.

eslint/eslint#7235

  • The request is to make func-names not warn when a function's name property has a non-empty string value in ES6. This would be behind an option.
  • @nzakas objected because that seems like a different purpose than the original rule.
  • @ilyavolodin and @btmills see the rule as ensuring names are present for debugging.

Resolution: The enhancement will be accepted and the documentation needs to be updated to better describe the purpose of the rule.

eslint/eslint#7230

  • This is a request for a prefer-object-spread rule or an enhancement to prefer-spread to suggest object spread in addition to array spread.
  • The contention is that instead of using Object.assign, we should suggest using object spread properties.
  • Syntax is currently stage 3.
  • An option on prefer-spread is preferred to a new prefer-object-spread rule.
  • Its utility doesn't seem to meet the bar for inclusion.

Resolution: The proposal doesn't meet the bar for inclusion.