Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kai Cataldo
    @kaicataldo

    TSC Summary:

    Quote from the discussion:

    Good point.

    Because I'm not sure if the bower_components directory in subdirectories is a common use-case or not, so I have left it as-is. I think that we have three directions for this.

    1. We keep it as-is.
    2. We change it to /**/bower_components/*.
    3. We remove /bower_components/* in favor of the ignorePatterns property of configs.

    In fact, the 3. is consistent with our stance -- we don't add exceptions anymore because we don't want to have the allowlist/denylist of all tools in the world.

    TSC Question:

    Should we stop ignoring bower_components by default in ESLint 7.x (or a later major release)?

    Kevin Partington
    @platinumazure
    :+1: for 7.x, but would be okay with waiting until later major if needed
    Kai Cataldo
    @kaicataldo
    :+1:
    Brandon Mills
    @btmills
    :+1: for 7.x
    Toru Nagashima
    @mysticatea
    :+1: for 7
    Kai Cataldo
    @kaicataldo
    Resolution is to not ignore /bower_components/* starting in v7
    It looks like we have a release issue for this week
    Kevin Partington
    @platinumazure
    I think this means we need the RFC updated with that decision. @mysticatea Will you make that update?
    Kai Cataldo
    @kaicataldo
    Toru Nagashima
    @mysticatea
    Yes, I will
    Kai Cataldo
    @kaicataldo
    Thank you, @mysticatea
    Kevin Partington
    @platinumazure
    Do we want to release? If we want to maintain the 4 week cycle, we can close eslint/eslint#12603 and let the bot generate a new release issue
    Kai Cataldo
    @kaicataldo
    Should we go ahead and close the release issue?
    Kevin Partington
    @platinumazure
    :+1: to close the release issue
    Brandon Mills
    @btmills
    :+1: to closing
    Kai Cataldo
    @kaicataldo
    :+1:
    Toru Nagashima
    @mysticatea
    :+1:
    Kai Cataldo
    @kaicataldo
    Okay, great! I think we're done then (unless we want to continue disucssing the LinterShell RFC)
    Toru Nagashima
    @mysticatea
    Thank you!
    Kai Cataldo
    @kaicataldo
    I know I personally need to give it another thorough read in its current iteration before I can feel like I have a really informed opinion
    Brandon Mills
    @btmills
    I also need to read through again
    I'll finish up the notes and then get to that
    Kevin Partington
    @platinumazure
    I'll give my thoughts in the RFC itself (I'm reading it now)
    Kai Cataldo
    @kaicataldo
    Okay, sounds good. Thanks everyone. Have a great rest of the week :wave:
    Brandon Mills
    @btmills
    :wave: thanks!
    Kai Cataldo
    @kaicataldo
    Bye!
    Kevin Partington
    @platinumazure
    :wave: Thanks everyone!
    Brandon Mills
    @btmills
    Meeting notes PR: eslint/tsc-meetings#157
    Brandon Mills
    @btmills
    :wave:
    Toru Nagashima
    @mysticatea
    Hello
    Kai Cataldo
    @kaicataldo
    :wave:
    Kevin Partington
    @platinumazure
    :wave:
    Kai Cataldo
    @kaicataldo
    I think we've reached quorum?
    Kevin Partington
    @platinumazure
    :+1:
    Who wants to facilitate?
    Kai Cataldo
    @kaicataldo
    I can!
    Kevin Partington
    @platinumazure
    @btmills Want to take notes?
    Brandon Mills
    @btmills
    I'll take notes
    Kai Cataldo
    @kaicataldo
    Looks like we have a short meeting today!
    First issue:
    Brandon Mills
    @btmills
    @platinumazure or @mysticatea will one of you respond on issues with our decisions?
    Kevin Partington
    @platinumazure
    Is today a TSC business meeting or a "review issues/PRs" meeting? (Or, given how short the agenda is, should we do both?)
    :wave: I will respond on issues
    Kai Cataldo
    @kaicataldo
    I'm up for that - how does everyone else feel?
    Brandon Mills
    @btmills
    Let's do it
    Kai Cataldo
    @kaicataldo
    Okay :+1:
    Kevin Partington
    @platinumazure
    :+1: Works for me
    Kai Cataldo
    @kaicataldo

    So for the above issue:

    TSC Summary:

    This is a follow-up from a TSC discussion on 2019/12/05 about whether configuration-related warnings could ever be added in a semver-minor release.

    I would like to allow us more flexibility on adding warnings for configuration or UX issues as semver-minor changes. Long-term, we need to be able to do this without having any impact on the exit code for the ESLint process.

    More background can be found in the initial issue post. Also, this is currently blocking eslint/rfcs#34.

    Long-term, we should probably fix this by creating a new location in the lint result object for lint run-level issues (e.g., configuration issues). Short-term, I would like to ask the TSC to consider allowing exceptions to the semver rules, on a case-by-case basis, for specific proposals in which the value of adding warnings is high enough to potentially justify breaking the users' build on semver-minor releases (especially if ESLint is already currently not working for the use case in question and we want to improve the UX and help users fix their issue). The process would be to nominate the issue on the TSC Agenda and ask the TSC to decide if the proposal should be accepted while adding warnings on a semver-minor release.

    This process change would be captured in the Maintainer Guide.

    TSC Question:

    Should we adopt a policy to allow, on a case-by-case basis, TSC discussion on issues that add warnings and whether they could be allowed in a semver-minor release?

    A follow up question I have: How do you foresee we'll move to a long-term solution?