It can't handle two standard variants being installed in package.json

[theScottyJam]

Here's what I did

I want to configure standardx to use TypeScript, and I took the following steps to do so.

Freshly install the standard plugin in vs-code (I got version v2.1.3).

All plugin settings are currently at their defaults. We want standardx to be used as the engine, so update the "standard: engine" setting to be "standardx". (This step doesn't actually seem to affect anything as far as I can tell - I'm assuming this option only takes effect if you explicitly disable "use package.json"? If so, that probably ought to be documented. I'm setting this config option anyways, just in case it is important).

Create a new example project:

• Make a new blank folder
• Create a package.json with the following content:

{
  "devDependencies": {
    "@typescript-eslint/parser": "^8.3.0",
    "standardx": "^7.0.0"
  },
  "standardx": {
    "parser": "@typescript-eslint/parser"
  }
}

• Create a dummy example.ts TypeScript file containing console . log( "hi there" as string ) ;
• Run npm i

Run npx standardx '**/*.ts'

Notice the following in the output:

standardx: Unexpected linter output:

Error: Failed to load config "standard" to extend from.
Referenced from: BaseConfig
    at configInvalidError (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:290:9)
    at ConfigArrayFactory._loadExtendedShareableConfig (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:883:23)
    at ConfigArrayFactory._loadExtends (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:781:25)
    at ConfigArrayFactory._normalizeObjectConfigDataBody (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:720:25)
    at _normalizeObjectConfigDataBody.next (<anonymous>)
    at ConfigArrayFactory._normalizeObjectConfigData (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:665:20)
    at _normalizeObjectConfigData.next (<anonymous>)
    at ConfigArrayFactory.create (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/config-array-factory.js:460:16)
    at createBaseConfigArray (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/cascading-config-array-factory.js:98:48)
    at new CascadingConfigArrayFactory (/home/scotty/my-project/node_modules/standard/node_modules/@eslint/eslintrc/lib/cascading-config-array-factory.js:234:30)

If you think this is a bug in `standardx`, open an issue: https://github.com/standard/standardx/issues

If you open up the file in vs-code, you'll notice that the standard plugin will fail to parse the file due to the same issue.

Ok, looks like it wants "standard" to be installed as well. Go ahead and add that in with npm i -D standard, then run npx standardx '**/*.ts' again.

It'll correctly lint the file:

standardx: Use JavaScript Standard Style (tweaked by standardx) (https://github.com/standard/standardx)
standardx: Run `standardx --fix` to automatically fix some problems.
  /home/scotty/my-project/example.ts:1:13: Multiple spaces found before ''hi there''.
  /home/scotty/my-project/example.ts:1:13: There should be no space after this paren.

Now open up the file in your editor. Notice that it'll give you a parsing error on any TypeScript syntax found in the file, in this case, the "as" keyword.

From what I gather, this is happening because in package.json, "devDependencies" contains both "standard" and "standardx", and that's confusing the plugin - it doesn't know which one to use for linting, and apparently it is picking "standard".

What I expected to happen

If both standard and standardx are found in package.json's dev dependencies, default to using standardx as the engine, not standard.

Some other good action items, but aren't necessarily required for this issue:

• Better document how to use standardx with TypeScript. The standardx README is very light, so it's difficult to know if I'm doing things the intended way or not.
• Tell the plugin users under what circumstances the "standard: engine" plugin config option is ignored.

What seems to have happened

See above.

Attached is the dependency tree for the example project described.

dependency-tree.txt

Workaround

I'm currently putting "standard" under "dependencies" instead of "devDependencies" to prevent this issue (it seems the plugin only looks under devDependencies for a linter engine). This is obviously not a good long-term solution, but it'll work for now until the project is put live.