Possible type mismatch

[pedro-w]

Not sure if this is a bug or not - there appears to be a mismatch between the type declared to be returned from StandardEngine's lintText in this repo and the implementation in the standard-engine repo

Here it is Promise<StanardReport>

https://github.com/standard/vscode-standard/blob/77896a055c3e98a34900d3d3d25aaf1cd24a1e31/server/src/server.ts#L136-L142

In standard-engine the actual return seems to be Promise<ESLint.LintResult[]>

https://github.com/standard/standard-engine/blob/c3a7f17ec6a3ddee6ef64dbde5be69553d4a5c39/index.js#L62-L73

  /**
   * Lint text to enforce JavaScript Style.
   *
   * @param {string} text file text to lint
   * @param {Omit<BaseLintOptions, 'ignore'|'noDefaultIgnore'> & { filename?: string }} [opts] base options + path of file containing the text being linted
   * @returns {Promise<import('eslint').ESLint.LintResult[]>}
   */
  async lintText (text, { filename: filePath, ...opts } = {}) {
    const eslintConfig = this.resolveEslintConfig(opts)
    const engine = new this.eslint.ESLint(eslintConfig)
    return engine.lintText(text, { filePath })
  }

I'm not an expert at this - I may have confused myself since it spans across at least two different code bases - is this an issue?

I ran into this because for some code

const report = await library.lintText(content, newOptions)

the type of report is inferred to be StanardReport by the editor, but at runtime it turns out to be an array of objects.

What version of this package are you using? v2.1.3

What operating system, Node.js, and npm version? Windows 11, node v16.16.0, npm 8.18.0

Are you willing to submit a pull request to fix this bug? Yes

[pedro-w]

I believe this is something to do with 'legacy modules' versus current; if anyone has more information I would be grateful to get it clear in my own mind

[theoludwig]

The API changed drastically in standard-engine v15, this VSCode extension should support v14 and v15 versions of Standard Engine currently. I'm not sure if it's still strongly typed, but I guess that's why the types differ.

What are you trying to do? In most cases, you don't need to use Standard, programmatically, the CLI works fine! You should be able to use programmatically the engine with the right types, it should not be related to the VSCode extension. For example (using standard@17):

import standard from 'standard'

// It should have the right signature, and types, no problems, and not related to the VSCode extension.
await standard.lintText('// some code...')

Where library came from in your example?