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
    Sounds like we're all generally supportive of this idea
    Do we want to hash this out in an issue? Or try to resolve it now?
    Toru Nagashima
    @mysticatea
    If the new warning appears in current normal usage, I think we should be careful.
    Kai Cataldo
    @kaicataldo
    I think the remaining question is how we define what kinds of warnings we're going to allow in semver-minor releases
    Brandon Mills
    @btmills
    I'd also be supportive of a distinct message type that separates core messages from lint messages, but that seems like a long-term solution, and I'm okay with this solution we could have immediately
    Kai Cataldo
    @kaicataldo
    Sounds like we should hash this out in an issue
    Kevin Partington
    @platinumazure
    I'm okay with that. :+1: I have a proposal that I can post in an issue.
    Kai Cataldo
    @kaicataldo
    So maybe accept this proposal with the caveat that we need to come up with a final design?
    Brandon Mills
    @btmills
    :+1:
    Kai Cataldo
    @kaicataldo
    :+1:
    Kevin Partington
    @platinumazure
    :+1:
    Kai Cataldo
    @kaicataldo
    @mysticatea Thoughts?
    Toru Nagashima
    @mysticatea
    :+1:
    Kai Cataldo
    @kaicataldo
    Resolution is to accept this proposal and to discuss the details in an issue that @platinumazure will create
    Next item:

    TSC Summary:

    Previously, we discussed ESLint v7 schedule (note). In the schedule, we will start to merge the PRs of breaking changes after the release cycle of this weekend. However, we don't plan to make a release this weekend because we no longer make releases every two weeks.

    Therefore, we should tweak the schedule.

    My proposal is that we start to merge the PRs of breaking changes after the release cycle that will be started on 20 December 2019 finished. Then we will release the first alpha in January 2020.

    TSC Question:

    When should we start to merge the PRs of breaking changes?

    (is there an easy way to do a multiline quote in markdown?)
    I'm :+1: for this. One thing to note is that, since there are a lot of holidays around this time, people might be less active than usual
    Brandon Mills
    @btmills
    Also :+1: (and I don't know of an easy way to do multiline quotes - I always use multiline editing in my editor to bulk insert/remove)
    Kevin Partington
    @platinumazure
    :+1:
    Kai Cataldo
    @kaicataldo
    Resolution is to accept this.
    Kevin Partington
    @platinumazure
    (For what it's worth, I don't anticipate being offline for most of the winter holiday)
    Kai Cataldo
    @kaicataldo

    Next item (same link):

    TSC Summary:

    Previously, we discussed about eslint/rfcs#40 (note). I emailed to @nzakas and he has inputted his insight. Then I updated eslint/rfcs#40.

    I'd like to ask for reviewing again.

    TSC Question:

    Should we approve eslint/rfcs#40 or request more changes?

    Kevin Partington
    @platinumazure

    I'm basically :+1: to making a better CLIEngine-like interface, but I share Nicholas's concerns about AsyncIterator results being a large change for not a lot of demonstrated benefits.

    I'm also a bit confused about whether this change is necessary given the parallel RFC for linting files in parallel-- maybe we should implement some sort of parallel linting but serialize the results. (Well, or maybe not. The point is, I'm not fully convinced about whether this RFC is necessary and whether it has enough benefit to justify the massive changes, even though they are no longer breaking.)

    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: