Reduce number of "Using tabs can lead to unpredictable results" messages to 1 per file

[pavelkornev]

User story.
In our org we have lots of legacy APIs which are using tabs as indentation. In this case Spectral produces lots of Warnings from the parser with a message Using tabs can lead to unpredictable results.

When I say "lots of", I mean it's really abnormally massive number... for the attached real-world OpenAPI file Spectral generates 21931 parser Warnings (22 THOUSANDS for a single file).

  ...
  630:1   warning  parser  Using tabs can lead to unpredictable results
  630:2   warning  parser  Using tabs can lead to unpredictable results
  630:3   warning  parser  Using tabs can lead to unpredictable results
  630:4   warning  parser  Using tabs can lead to unpredictable results
  631:1   warning  parser  Using tabs can lead to unpredictable results
  631:2   warning  parser  Using tabs can lead to unpredictable results
  631:3   warning  parser  Using tabs can lead to unpredictable results
  631:4   warning  parser  Using tabs can lead to unpredictable results
  632:1   warning  parser  Using tabs can lead to unpredictable results
  632:2   warning  parser  Using tabs can lead to unpredictable results
  632:3   warning  parser  Using tabs can lead to unpredictable results
  632:4   warning  parser  Using tabs can lead to unpredictable results
  632:5   warning  parser  Using tabs can lead to unpredictable results
  633:1   warning  parser  Using tabs can lead to unpredictable results
  633:2   warning  parser  Using tabs can lead to unpredictable results
  633:3   warning  parser  Using tabs can lead to unpredictable results
  ...

The problem with this is that other more serious issues simply invisible in this massive spam from this Warning...

Related issues:
#1550

Describe the solution you'd like
Return a single Warning of this kind per file. Normally, the file is using either tabs, or spaces. In case of tabs, it doesn't make sense to spam the output with the same issue for each occurrence. If developer decides to change indentation in the file, most likely (s)he will use IDE feature for that which will change it for the whole file anyway, not just in one single occurrence.

BTW, Could you please give us some guidance on what kind of unpredictable results the users may face if they use tabs in their OpenAPI files? This is the most frequently asked question when they see this issue from the tooling.

Thank you.

[pavelkornev]

This issue was caused mainly by our misuse of the YAML parser. We used YAML parser for both — YAML & JSON files. Due to some other differences in YAML parser behaviour with working with JSON files, we decided to differentiate explicitly these file types and use a proper parser for each.

So, this issue is no longer relevant -> closing.

[David-Kyrat]

Hi i am still getting the same issue, could provide explaination on how it was resolved (since this issue is closed)

[githorse]

Yeah not sure why it's closed ... I don't get thousands of errors but I do get one error per line, which is enough to totally obscure any real problems.

[bpottier]

Adding that we are also still seeing this issue. Seems like its not actually resolved?

[rudfoss-rr]

I've run into this issue myself and this thread came up. I've written a small script that can lint json files using the appropriate parser. I've also tried to open a PR to have the "parser" option added to the CLI. This is the script I came up with:

npm i -D @stoplight/spectral-core @stoplight/spectral-formatters @stoplight/spectral-ruleset-bundler

#!/usr/bin/env node

// Due to this issue: https://github.com/stoplightio/spectral/issues/2720
// we cannot use the spectral-cli directly to lint our openapi files.
// This script performs the same job, but uses the appropriate parser.

import fs from "node:fs"
import path from "node:path"

import { Spectral, Document, ISpectralDiagnostic } from "@stoplight/spectral-core"
import { stylish } from "@stoplight/spectral-formatters"
import { Json, Yaml } from "@stoplight/spectral-parsers" // make sure to install the package if you intend to use default parsers!
import { bundleAndLoadRuleset } from "@stoplight/spectral-ruleset-bundler/with-loader"
import { fetch } from "@stoplight/spectral-runtime"
import { DiagnosticSeverity } from "@stoplight/types"

// const { Spectral, Document } = spectralCore
// const { fetch } = spectralRuntime

const workspaceRoot = path.resolve(__dirname, "../../..")

// The Parser type did not fit directly but docs says it should
// ref: https://docs.stoplight.io/docs/spectral/eb68e7afd463e-spectral-in-java-script
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const getParser = (filePath: string): any => {
	if (filePath.toLocaleLowerCase().endsWith(".json")) return Json
	return Yaml
}

const attachSource =
	(source: string) =>
	(result: ISpectralDiagnostic): ISpectralDiagnostic => ({
		...result,
		source
	})

const start = async ([filePath]: string[]) => {
	if (!filePath) {
		throw new Error("Missing [filepath] argument relative to workspace root.")
	}

	console.log(`Linting file ${filePath}...`)
	const document = new Document(fs.readFileSync(filePath, "utf8"), getParser(filePath))
	const spectral = new Spectral()

	const rulesetFilepath = path.join(workspaceRoot, ".spectral.yaml")
	spectral.setRuleset(await bundleAndLoadRuleset(rulesetFilepath, { fs, fetch }))

	const results = await spectral.run(document, { ignoreUnknownFormat: false })
	const resultsWithSource = results.map(attachSource(filePath))
	console.log(stylish(resultsWithSource, { failSeverity: DiagnosticSeverity.Information }))
	if (results.length > 0) {
		process.exit(1)
	}
	process.exit()
}

start(process.argv.slice(2)).catch((error) => {
	console.error(error)
	process.exit(1)
})