Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kevin Partington
    @platinumazure
    Sorry, I spoke badly. Okay, we have lint warnings and configuration warnings. Let's ignore deprecation warnings for now. I'm more concerned about introducing warning-only configuration messages, and having that be restricted to semver-major only under the current policy.
    Kai Cataldo
    @kaicataldo
    So, just to be clear, are we trying to come to consensus on the issue brought up in that RFC?
    Agreed with @platinumazure
    Kevin Partington
    @platinumazure
    Yeah, let's focus on the RFC's concern please. I might have broadened the issue inappropriately
    Kai Cataldo
    @kaicataldo
    @mysticatea Do you mind expanding on your point above?
    FWIW, I'm supportive of introducing warnings in semver-minor releases
    Toru Nagashima
    @mysticatea
    I'm sorry, I'm failing translation English...
    Kai Cataldo
    @kaicataldo
    No problem!
    And updating our semver policy to include that
    Though I think it would be useful in the future to try to come up with a better way to distinguish between warnings caused by a linting run and those that are just trying to provide information to the user
    @btmills Would love to hear your thoughts
    Toru Nagashima
    @mysticatea
    If it's adding warnings to improve UX, I'm fine to do in minor releases.
    Brandon Mills
    @btmills
    I'd also be supportive of changing the semver policy to allow us to add configuration warnings in semver-minor releases. To me, the damage from someone unknowingly having the tool do something different than what they intended is greater than having to fix it during an upgrade
    Sounds like I agree with @platinumazure and @kaicataldo
    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