New: Implement cacheStrategy (refs eslint/rfcs#63)

[chambo-e]

Hello 👋

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[X] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

This is a follow up of #13713 which seems abandoned.

I corrected the tests by binding every stubs to the newly created sinon sandbox

Is there anything you'd like reviewers to focus on?

[eslint-deprecated]

Hi @chambo-e!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The issue reference must be formatted as follows:

  If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use (refs #1234) instead of (fixes #1234).

  Here are some good commit message summary examples:

  Build: Update Travis to only test Node 0.10 (refs #734)
  Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
  Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
  

Read more about contributing to ESLint here

[eslint-deprecated]

Hi @chambo-e!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The issue reference must be formatted as follows:

  If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use (refs #1234) instead of (fixes #1234).

  Here are some good commit message summary examples:

  Build: Update Travis to only test Node 0.10 (refs #734)
  Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
  Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
  

Read more about contributing to ESLint here

[eslint-deprecated]

Hi @chambo-e!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The issue reference must be formatted as follows:

  If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use (refs #1234) instead of (fixes #1234).

  Here are some good commit message summary examples:

  Build: Update Travis to only test Node 0.10 (refs #734)
  Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
  Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
  

Read more about contributing to ESLint here

[eslint-deprecated]

Hi @chambo-e!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The issue reference must be formatted as follows:

  If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use (refs #1234) instead of (fixes #1234).

  Here are some good commit message summary examples:

  Build: Update Travis to only test Node 0.10 (refs #734)
  Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
  Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
  

Read more about contributing to ESLint here

[nzakas]

Overall looks good, just a couple of things to clarify.

[royriojas]

Very nice

[nzakas]

LGTM. I'd like another set of eyes on this before merging.

[mdjermanovic]

It would be good to also fix the behavior in the case that is described here:

eslint/rfcs#63 (comment)

Edit: Not in this PR.

[nzakas]

@mdjermanovic you indicated in the RFC that this wasn't a blocker. Is that something we can manage via a separate issue rather than blocking this PR for it?

[mdjermanovic]

Agreed we shouldn't address that in this PR. The issue might get fixed in file-entry-cache (jaredwray/file-entry-cache#22).

I meant it shouldn't be a blocker for this feature. If it isn't fixable, we can tell users to always delete the cache file before changing the strategy.

[royriojas]

@mdjermanovic @nzakas published file-entry-cache@6.0.1 with @mdjermanovic fix

[mdjermanovic]

@royriojas thanks!

@chambo-e can you update file-entry-cache to ^6.0.1 in package.json?