Skip to content

Latest commit

 

History

History
126 lines (81 loc) · 8.17 KB

2019-12-05.md

File metadata and controls

126 lines (81 loc) · 8.17 KB
Raw

2019-December-05 ESLint TSC Meeting Notes

Transcript

https://gitter.im/eslint/tsc-meetings/archives/2019/12/05

Attending

  • Kevin Partington (@platinumazure) - TSC
  • Brandon Mills (@btmills) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • Kai Cataldo (@kaicataldo) - TSC

Additionally, the following individuals are not in attendance but support consensus:

  • Nicholas C. Zakas (@nzakas) - TSC
  • Gyandeep Singh (@gyandeeps) - TSC

Topics

New: Include node version in cache

  • TSC Summary: This PR proposes to include the Node version when hashing the cache key, ensuring that the cache is busted when consecutive linting runs are executed with different Node versions.
  • TSC Question: Should we accept this?
  • @platinumazure and @ilyavolodin already left a 👍 on the pull request.
  • 👍 from @mysticatea, @kaicataldo, and @btmills.

Resolution: The proposal is accepted.

Can adding warnings (without adding errors) ever be semver-minor?

TSC Summary

In this comment, I noted that it is currently considered a breaking change to add warnings for any reason (including outside of lint rules), because of eslint --max-warnings=0.

Our semver policy currently states that causing build errors on any enhancement should always be treated as semver-major (and this is correct and sensible). When someone is using --max-warnings, any new warnings can cause a build error.

At the same time, warnings are currently our best way of reporting non-fatal errors from core (e.g., if there are minor issues with disable comments, deprecated rules, etc.). Errors and warnings are fundamentally different: Errors change the exit code of CLI processes and generally represent issues that users must resolve, but warnings do not change the exit code of CLI processes and generally represent minor issues that users could ignore. Warnings only become issues that users must resolve if they use --max-warnings in the CLI, and that is an opt-in decision.

TSC Question

Can we consider adding new warnings in semver-minor enhancements, as long as they are only warnings? As part of this, can we consider --max-warnings and any CLIEngine equivalent as the user bypassing our semver policy, similar to eslint:all?

If not, could we design a new way to communicate to users, in such a way that RFCs which add information for users could do so without semver risks? For example:

  • New message severity that can never trigger nonzero exit code even with --max-warnings
  • A new report section for informational messages unrelated to per-file linting

Discussion

  • This is currently blocking RFC #34.
  • We currently conflate linting warnings, configuration warnings, and deprecation warnings, so we aren't able to treat them separately.
  • @mysticatea references the Node.js guide on deprecations and feels that runtime deprecations should not occur in minor versions.
  • This proposal only needs a decision on configuration warnings, so we can ignore deprecation warnings for now.
  • @kaicataldo is in favor of updating our semver policy to permit introducing warnings that provide information to the user in semver-minor releases.
  • @mysticatea is fine adding warnings to improve UX in minor releases, but not adding warnings for what is current normal usage.
  • @btmills is supportive of changing the semver policy to allow adding configuration warnings in semver-minor releases because minor pain to fix a configuration issue during an upgrade is better than allowing the tool to continue doing something different than intended.
  • @kaicataldo and @btmills both express interest in a future change to separate configuration messages from lint messages.
  • @platinumazure can open an issue with a proposal detailing which kinds of warnings can be added in semver-minor releases.
  • 👍 to accepting this proposal pending a final design hashed out in @platinumazure's issue from @btmills, @kaicataldo, @platinumazure, and @mysticatea.

Resolution: The proposal is accepted in principle, and @platinumazure will open an issue with a detailed design.

When to start merging ESLint v7 breaking changes

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?

  • @kaicataldo notes that since there are a lot of holidays around this time, people might be less active than usual.
  • 👍 from @kaicataldo, @btmills, and @platinumazure

Resolution: The proposal is accepted, and we will start merging breaking changes after concluding the release cycle that will start on 2019-12-20.

New: LinterShell Class Replacing CLIEngine

  • 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?
  • @platinumazure shared others' concerns about using AsyncIterator<LintResult> as an interface to return lint results, but that has since been replaced by Promise<LintResult> in the updated RFC.
  • In order to support ESM configuration files and plugins, we need to load them asynchronously.
  • In order to support parallel linting, the lint result also needs to be asynchronous.
  • @platinumazure is convinced of the general need for this.
  • @btmills is more favorably inclined toward this version after earlier feedback has been addressed and would like to do a thorough pass with the goal of merging.
  • @kaicataldo proposes reviewing the RFC outside the meeting.
  • 👍 from @mysticatea, @btmills, and @platinumazure.

Resolution: We will review the RFC in its current state and give feedback there.

Remove bower_components from default ignores

TSC Summary

Quote from the discussion in RFC51:

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)?

  • 👍 from @platinumazure, @kaicataldo, @btmills, and @mysticatea to removing in v7.

Resolution: We will remove bower_components from the default ignores in ESLint v7. @mysticatea will update the RFC.

Scheduled release for December 6th, 2019

  • If we want to maintain the 4 week release cycle, we can close this and let the bot generate a new release issue.
  • 👍 to closing from @platinumazure, @btmills, @kaicataldo, and @mysticatea.

Resolution: We will close this issue and pick up the next release cycle on December 20th.