What problem does this solve?
Currently the mapping from LintKind to colour, currently only used when Harper interacts with the web, is duplicated in two TypeScript files:

• packages/lint-framework/src/lint/lintKindColor.ts
• packages/web/src/lib/lintKindColor.ts

(The two files are identical by the way)

It seems to me the colours should:

1. have a single source of truth
2. should be available to users of harper-core, not just web-based ones.

Proposed Solution

1. The colours could be part of the LintKind enum in harper-core/src/linting/lint_kind.rs.
2. Or they could be external to the enum but associated with its elements externally as some kind of map, probably in the same source file.

How to make it available to the TypeScript components is a more important question to answer. I can think of two ways:

1. Generate the two lintKindColor.ts files as part of the build process.
2. Provide some kind of API or APIs through which the TypeScript code can fetch the entire mapping of LintKinds to colours, or fetch the specific colour for a given LintKind.

At the moment the TypeScript code defines the most efficient way possible as a const literal:

const LINT_KIND_COLORS = {
	Agreement: '#228B22', // Forest green
	...
} as const;

I'm not sure how essential that is. Naive implementations of an API to fetch the colours not be as efficient. Generating the TypeScript files at build time would maintain the efficiency. Non-naive implementations of an API would fall somewhere between.

I played with a few ways to implement an API a few weeks ago and found it quite a bit more cumbersome than I expected. Somebody more skilled at Rust than me can surely do better.

Examples
Here's what I was playing with, to use the colours in a summary when linting on the commandline. But I'm sure there would be many uses for people making tools that use harper-core or harper.js

Component

• Core engine
• Plugin/Extension
• Other: _____