Change Request: Eslintcache relative

[brenelz]

ESLint version

v8.26.0

What problem do you want to solve?

I am currently trying to use the .eslintcache file in our jenkins ci.

Is there anyway the cache can use relative file paths? In our instance each branch is in a seperate dir but I want to reuse the cache.

What do you think is the correct solution?

In order to move the .eslintcache around it would be great if the cache filePaths were relative

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[mdjermanovic]

Hi @brenelz, thanks for the issue!

I think this is generally doable. We'd need to discuss details, like whether this needs a new option and what should be the base path (directory to which the file paths would be relative; would it be the current working directory, or location of the cache file, or something else). This is a non-trivial change in the core, so I think it should go through the RFC process, but let's hear more opinions from the team first.

[brenelz]

If its a non-trivial change its probably not worth it. Seems like no one has really asked for it besides me. We were just trying to use the cache in our ci which I think we are unable to do currently.

[brenelz]

Another option very specific to my use case would be if we could not include the path in hashOfConfig if that makes sense

[nzakas]

Yeah, we’d need an RFC for this as it has the potential to break current cache file usage.

[CSchulz]

Who can initiate this rfc request? We are also struggling with caching.

Why not using a hybrid scenario for the paths? Cutting the absolute path to a relative path and always store the relative path for the future.
As long as nobody moves the workspace around there is no breaking change for the cache itself.

[nzakas]

Anyone can initiate an RFC. Some people check in their cache file, so any change to the cache format is a breaking change. We can't know for sure where people are storing cache files or how else they might be used.

[CSchulz]

I can't believe anyone is using absolute paths if people want to check in their cache files.
Otherwise to prevent some breaking changes, can we add a third strategy for the cache using relative paths?

[nzakas]

@CSchulz you can feel free to propose whatever you want. As already stated, we would just need an RFC to consider it.

[aaronabf]

If its a non-trivial change its probably not worth it. Seems like no one has really asked for it besides me. We were just trying to use the cache in our ci which I think we are unable to do currently.

I second this feature! I had opened an issue for this as well #16741.

[herzaso]

+1.
I wanted to use caching and check in the cache file so that other developers in my organization (and the CI) would use that cache, but it is currently not feasible.
The biggest problem is the CI - since we use docker to run the lint, it can't maintain the .eslintcache file so we have to check it in, but then I don't think that the CI should write anything to my repo

[majo44]

+1 on our big monorepo (500 packages) we also want to share the .eslintcache especially to save CI time.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[Rec0iL99]

WIP. Don't close. @CSchulz has opened a RFC.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[github-actions]

This issue was auto-closed due to inactivity. While we wish we could keep responding to every issue, we unfortunately don't have the bandwidth and need to focus on high-value issues.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[cs6cs6]

I would like to see this proceed.

[brenelz]

Personally I don't have a specific need for this anymore, but I think it would still be nice

[cs6cs6]

I do. I'm prototyping it, and if it works I'll try to submit this back.

---

• lib/options.js: Add the option to specify a non default estlintcache directory structure, around line 313:

   option: cachefolderstorage
   type: String
   enum: ["full", "relative"],
   default: "full"
   description: "Indicates how an eslintcache will internally store directories. "relative" allows for the same cache to be used at different directory paths. "full" is the legacy, default behavior where the full file path is encoded in the eslintcache.
 

• conf/default-cli-options.js: Add the name "cachefolderstorage" with a default of "full" around line 25

• eslint/eslint-hepers.js: Modify processOptions function around line 662 to have the field "cachefolderstorage" with a default of "full"

• lib/eslibt/flat-eslint.js: add a debug printout to state what kind of directory struture is used. In function "lintFiles" which starts around line 733, the list of file directory paths is created from the pattern passed in on the cli. This list of files is ultimately what gets written to the eslintcache. Those file names are full path names.
  The easiest change here with the least side effects is likely just to change the way the result object is stored. On Line 871 the code looks like this:

     if (lintResultCache) {
                            lintResultCache.setCachedLintResults(filePath, config, result);
                        }

It would likely be best to look at the config option cachefolderstorage here, and see if filePath should be stored as a relative or a full path.

Some unit tests will definitely need to be added to the flat-eslint tests, and the option-parser tests.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[CSchulz]

@cs6cs6 I am out of time at the moment, but I would suggest to take over my rfc request or we work together?

[nzakas]

This isn't stale, we have an RFC open:
eslint/rfcs#114

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[nzakas]

We have an RFC that hasn't been updated in a bit. Will ping the author.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[nzakas]

We are waiting on the RFC to be picked up.

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[snitin315]

Assigned it to the RFC author, to avoid stale-bot messages.