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.

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

4.1 breaks on extending multiple configs from a plugin #8792

Closed
corbinu opened this Issue Jun 24, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@corbinu
Contributor

corbinu commented Jun 24, 2017

Tell us about your environment

  • ESLint Version: 4.1.0
  • Node Version: 8.0.3
  • npm Version: 5.0.3

What parser (default, Babel-ESLint, etc.) are you using?
default and typescript

Please show your full configuration:

{
  "plugins": [
    "@corbinu/corbinu"
  ],
  "extends": [
    "plugin:@corbinu/corbinu/base",
    "plugin:@corbinu/corbinu/node",
    "plugin:@corbinu/corbinu/lodash",
    "plugin:@corbinu/corbinu/relax"
  ],
  "rules": {
    "node/no-missing-require": "off"
  }
}

What did you do? Please include the actual source code causing the issue.
I upgraded to 4.1 and began seeing output as if "sourceType" was not set to module.

If I remove all the extends except for "plugin:@corbinu/corbinu/base" then things begin to resolve again or if I paste and merge the configs from each of those then everything reacts normally

Sorry know it makes it more complex to dig into my plugin the source is here: https://gitlab.com/corbinu/eslint-plugin-corbinu

It is only a set of configs no rules of my own.

@not-an-aardvark

This comment has been minimized.

Show comment
Hide comment
@not-an-aardvark

not-an-aardvark Jun 24, 2017

Member

The issue is that we're caching configs by file path here, and we're not accounting for the fact that plugin-loaded configs all come from the same file path for a particular plugin. As a result, if two configs from the same plugin are loaded simultaneously, only the one with higher precedence is getting used, and the other is getting pulled from the cache as the same object as the first config.

Member

not-an-aardvark commented Jun 24, 2017

The issue is that we're caching configs by file path here, and we're not accounting for the fact that plugin-loaded configs all come from the same file path for a particular plugin. As a result, if two configs from the same plugin are loaded simultaneously, only the one with higher precedence is getting used, and the other is getting pulled from the cache as the same object as the first config.

@corbinu

This comment has been minimized.

Show comment
Hide comment
@corbinu

corbinu Jun 24, 2017

Contributor

@not-an-aardvark Thanks so much for looking into this I am just going to pin on 4.0.x for now :)

Contributor

corbinu commented Jun 24, 2017

@not-an-aardvark Thanks so much for looking into this I am just going to pin on 4.0.x for now :)

not-an-aardvark added a commit that referenced this issue Jun 25, 2017

Fix: ensure configs from a plugin are cached separately (fixes #8792)
Config files are cached by file path to avoid needing to load the same config file twice. However, configs provided by plugins all have the same file path (the index file of the plugin). This created a bug when loading multiple configs for the same plugin where only the highest-precedence config from that plugin would be loaded. All other configs from that plugin would be considered identical by the cache, so they would all end up getting pulled from the cache as the same config.

This commit updates the caching logic to use the config full name as a cache index. This is still the file path when resolving a config from the filesystem, but it is the unique plugin config identifier (e.g. 'plugin:foo/node-config') when resolving a plugin config.

@eslint eslint bot locked and limited conversation to collaborators Feb 6, 2018

@eslint eslint bot added the archived due to age label Feb 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.