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.

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

TypeScript 3.9.2: Error: Failed to load config "xo-typescript" to extend from #483

Closed
jonahsnider opened this issue May 12, 2020 · 8 comments · Fixed by dwmt/konvenient#4

Comments

@jonahsnider
Copy link
Contributor

This might be an issue with the XO CLI, not sure though.

Error: Failed to load config "xo-typescript" to extend from.
Referenced from: BaseConfig
    at configMissingError (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:265:9)
    at ConfigArrayFactory._loadExtendedShareableConfig (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:826:23)
    at ConfigArrayFactory._loadExtends (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:731:25)
    at ConfigArrayFactory._normalizeObjectConfigDataBody (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:660:25)
    at _normalizeObjectConfigDataBody.next (<anonymous>)
    at ConfigArrayFactory._normalizeObjectConfigData (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:596:20)
    at _normalizeObjectConfigData.next (<anonymous>)
    at createConfigArray (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:340:25)
    at ConfigArrayFactory.create (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/config-array-factory.js:395:16)
    at createBaseConfigArray (/home/runner/work/bot/bot/node_modules/eslint/lib/cli-engine/cascading-config-array-factory.js:86:48)
@sindresorhus sindresorhus transferred this issue from xojs/eslint-config-xo-typescript Jun 3, 2020
@jonahsnider
Copy link
Contributor Author

jonahsnider commented Jun 3, 2020

Getting this error with XO v0.32.0 and TypeScript v3.8.3.

Upgrading to TypeScript v3.9.3 fixed the error.

@ranisalt
Copy link

I was having this issue with Typescriot v3.8.3, upgrading to v3.9.7 now gives the same error but with:

Error: Failed to load plugin 'react' declared in 'BaseConfig » /home/rsa/go/src/brewery.doctype.se/skyfall/frontend/node_modules/eslint-config-xo-react/index.js': Cannot find module 'eslint-plugin-react'

@luludotdev
Copy link
Contributor

Getting this same error with TypeScript v4.0.2

@jonahsnider
Copy link
Contributor Author

This is almost certainly the same root cause as why having a different Prettier version breaks. However XO is importing or using other modules isn't resilient to version changes and seems to force you to use whatever version is specified in the XO package.json.

@LRNZ09
Copy link

LRNZ09 commented Aug 31, 2020

I'm also having this issue with TypeScript v4.0.2

EDIT: resolved temporarily adding packages manually as suggested from this comment #454 (comment)

@ryparker
Copy link

ryparker commented Sep 17, 2020

yarn add --dev eslint-config-xo-typescript fixes it for me.

@voxpelli
Copy link
Contributor

voxpelli commented Nov 5, 2020

Reason is this:

When ESLint loads an extended shareable config it does so relative to the file it is imported from:

  1. new CLIEngine() sets up the baseConfig
  2. The baseConfig is forwarded to createBaseConfigArray()
  3. createBaseConfigArray() calls configArrayFactory.create()](https://github.com/eslint/eslintrc/blob/4440df8237a127e15cbde5c697353e1224f12ec1/lib/cascading-config-array-factory.js#L91-L101), but [forwards _only_ a name`
  4. Within create() a context (ctx), containing the name and filePath, is created is created and the config data gets normalized using [_normalizeConfigData()]

Within _normalizeConfigData() the data eventually arrives at *_normalizeObjectConfigDataBody() where it loads the extends and as part of that tries to load eslint-config-xo-typescript (as the extended shareable config that it is).

And here's the core:

In _loadExtendedShareableConfig() the config is loaded relative to the provided filePath (the one that was missing in step 3. above), and if no filePath is set, then relative to a placeholder file within cwd.

It loads using resolver.resolve](moduleName, relativeToPath) which essentially is a wrapper around the Node.js core Module.createRequire(relativeToPath).resolve(moduleName).

So what happens is:

  1. xo creates a virtual ESLint config, a baseConfig, and tells ESLint CLIEngine to run that from the cwd of the main project.
  2. The main project doesn't have any of the extended shareable configs as dependencies to it.
  3. xo has the extended shareable configs as dependencies to itself.
  4. ESLint can therefore only find the extended shareable config if they have been hoisted to the top level of node_modules and through that hoisting becomes require:able from the top project.
  5. Neither npm or yarn makes any guaranties that any dependencies other than the ones defined in the top project will be possible to require from there.
  6. Due to the nature of this modules they will likely get hosted most of the time, but eg. I ran into a case (xo currently fails when installed with yarn 1.x sindresorhus/type-fest#137) where yarn 1.x wouldn't hoist eslint-config-xo-typescript while npm would. This only happens because of the incorrect reliance on hoisting.

Solution?

Not really sure. Maybe one of:

  • Try to set the cwd to the xo folder, as require() will find modules higher up in the folder hierarchy, so it will find the hoisted modules.
  • There is a resolvePluginsRelativeTo option for CLIEngine, maybe one could make xo provide the config through a plugin instead and point resolvePluginsRelativeTo to the folder of xo itself?
  • Convince the ESLint team to add a resolveExtendedShareableConfigsRelativeTo that mimics resolvePluginsRelativeTo? (Which they may be reluctant as CLIEngine is deprecated, Move from deprecated ESLint.CLIEngine #474)

@jonahsnider
Copy link
Contributor Author

I think XO v0.46.x fixed this issue by using bundledDependencies. Has anyone still been getting this error on the recent versions of XO & TypeScript?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants