Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Brandon Mills
    @btmills
    I believe the AsyncIterator was replaced with a Promise in the latest change, wasn't it?
    Kai Cataldo
    @kaicataldo
    Isn't this necessary for us to support ESM config files though?
    Toru Nagashima
    @mysticatea
    AsyncIteration was for formatters that prints progress. And I have removed it. Because now getFormatter() API returns wrapper instead of formatter itself, so I think that we can add new API to formatters without breaking changes.
    Kai Cataldo
    @kaicataldo
    and plugins
    Kevin Partington
    @platinumazure
    @kaicataldo Well, one option might be for us to say we won't support an ESM config file, and that users should use .eslintrc.cjs.
    Or would that case still break in our current CLIEngine?
    @mysticatea Thank you for clarifying-- I apologize, I missed that change. I'm more okay with returning Promise<LintResult> and letting the caller aggregate the results
    Brandon Mills
    @btmills
    FWIW, I just went through all of @nzakas' comments, and it looks like they were all addressed
    Kevin Partington
    @platinumazure
    Okay, so even an .eslintrc.cjs just cannot work with plugins/parsers that are ESM? Am I reading that correctly?
    Brandon Mills
    @btmills
    I'm much more positive on this than I was the original version. It ends up with an API that supports async linting and ESM config files/plugins and avoids some of the sharp edges from CLIEngine yet stays reasonably close to the existing API for a lower migration hurdle
    Kai Cataldo
    @kaicataldo
    @platinumazure Right - the loading mechanism needs to be async for any plugins or parsers that are shipped as ESM
    Kevin Partington
    @platinumazure
    Okay-- now I'm convinced of the general need for this. I am reviewing the current RFC text
    Thanks for clarifying @kaicataldo
    Kai Cataldo
    @kaicataldo
    For the sake of time, do we want to say that we'll look at this right after this meeting (or revisit at the end) and give our reactions on the RFC itself?
    Brandon Mills
    @btmills
    I'll summarize by saying that I'm favorably inclined toward the current direction, and I'm willing to put in the time to do a detailed pass through the RFC with the goal of polishing it up and merging if others feel similarly
    Kai Cataldo
    @kaicataldo
    I feel similarly
    Toru Nagashima
    @mysticatea
    :+1:
    Brandon Mills
    @btmills
    :+1:
    Kevin Partington
    @platinumazure
    :+1:
    Kai Cataldo
    @kaicataldo
    Okay! We've resolved to review the RFC in its current state and give feedback on the RFC itself
    Next item:

    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