Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Fix] exportMap: improve cacheKey when using flat config #3072

Merged
merged 3 commits into from
Sep 26, 2024
Merged

[Fix] exportMap: improve cacheKey when using flat config #3072

merged 3 commits into from
Sep 26, 2024

Commits on Sep 26, 2024

  1. [utils] [new] hash: add support for hashing functions

    @michaelfaith @ljharb
    michaelfaith authored and ljharb committed Sep 26, 2024
    Configuration menu
    Copy the full SHA
    468321a View commit details
    Browse the repository at this point in the history

  2. [utils] v2.12.0

    @ljharb
    ljharb committed Sep 26, 2024
    Configuration menu
    Copy the full SHA
    96cad2a View commit details
    Browse the repository at this point in the history

  3. [Fix] exportMap: improve cacheKey when using flat config 

    Discovered this issue in import-js#2996 (comment)

This change improves the logic for generating the cache key used for both the exportMap cache and resolver cache when using flat config. Prior to this change, the cache key was a combination of the `parserPath`, a hash of the `parserOptions`, a hash of the plugin settings, and the path of the file. When using flat config, `parserPath` isn't provided. So, there's the possibility of incorrect cache objects being used if someone ran with this plugin using different parsers within the same lint execution, if parserOptions and settings are the same. The equivalent cacheKey construction when using flat config is to use `languageOptions` as a component of the key, rather than `parserPath` and `parserOptions`. One caveat is that the `parser` property of `languageOptions` is an object that oftentimes has the same two functions (`parse` and `parseForESLint`). This won't be reliably distinct when using the base JSON.stringify function to detect changes. So, this implementation uses a replace function along with `JSON.stringify` to stringify function properties along with other property types.

To ensure that this will work properly with v9, I also tested this against import-js#2996 with v9 installed. Not only does it pass all tests in that branch, but it also removes the need to add this exception: import-js#2996 (comment)
    @michaelfaith @ljharb
    michaelfaith authored and ljharb committed Sep 26, 2024
    Configuration menu
    Copy the full SHA
    ab0941e View commit details
    Browse the repository at this point in the history