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
    Seems like introducing more linting warnings in rules should be treated the same way we do changes that increase errors reported in rules, but I agree that console warnings around feature deprecation or tool usage can be useful and should not have to be treated as a breaking change.
    Brandon Mills
    @btmills
    We've had several times where we wished we could report something to users that wasn't necessarily from a lint rule
    Toru Nagashima
    @mysticatea
    Increasing warnings for errored stuff is fine. But, increasing warnings for existing features (i.e., runtime-deprecation) in minor releases is not good to me.
    In my head, there is https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#deprecations.
    Kevin Partington
    @platinumazure
    Yeah... If we decide to keep lint warnings and deprecation warnings in the same array, I'd like to differentiate our policy on adding more lint messages vs adding more deprecation warnings
    Kai Cataldo
    @kaicataldo
    Sure, I'm just saying I think there's value in being able to log information to users - maybe that was a bad example
    Configuration issues, etc. are definitely more the use case I'd like to support (agreed we shouldn't spam deprecation warnings)
    Toru Nagashima
    @mysticatea
    Then, to me, warning on // global/// eslint is a runtime-deprecation.
    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:
    https://github.com/eslint/tsc-meetings/issues/156#issuecomment-561964344

    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.