Allow configuring rules

[camchenry]

The headless mode is currently working well for enabling rules on a per-file basis. However, there isn't any way to configure rules on a per-file basis (and yes, configuration would likely need to be specified for each file, because it can change depending on glob patterns in the config to apply enable/disable different rules and configurations).

I suggest we allow passing rules as an object, similar to the .oxlintrc.json or .eslintrc format. The keys in rules are the rule names, such as no-floating-promises. The values in the rules object are the configurations. If a rule name is not present as a key, assume it is disabled by default. If an empty object is passed, use the default configuration options.

For example:

{
  "files": [
    {
      "file_path": "/absolute/path/to/file.ts",
      "rules": {
        "no-floating-promises": {
          "allowForKnownSafeCalls": [
            { "from": "file", "name": "safe", "path": "input.ts" }
          ]
        },
      },
    }
  ]
}

[auvred]

The problem is that Go doesn't have nice enums like Rust does, so the options schema differs slightly from the one used by typescript-eslint. For example, typescript-eslint's TypeOrValueSpecifier is a discriminated union, whereas tsgolint's TypeOrValueSpecifier is just a struct containing all relevant fields.

Ideally, the configuration definition should be written once, and the Go code, Rust code, and documentation should be generated automatically from that single source. Maybe JSON Schema could work?

[camchenry]

The problem is that Go doesn't have nice enums like Rust does, so the options schema differs slightly from the one used by typescript-eslint. For example, typescript-eslint's TypeOrValueSpecifier is a discriminated union, whereas tsgolint's TypeOrValueSpecifier is just a struct containing all relevant fields.

Unfortunately, I have no idea what to suggest here as I'm unfamiliar with Go 😅 It sounds like maybe we need to write a configuration parser that can parse the structs from arbitrary JSON.

Ideally, the configuration definition should be written once, and the Go code, Rust code, and documentation should be generated automatically from that single source. Maybe JSON Schema could work?

Might be a good idea. Synchronizing across repositories will be difficult, but maybe at least within tsgolint we could use codegen to write some of the config parsing code for us? We have a number of scripts in oxc that write any tedious implementations over many different shapes of data.

[Scalahansolo]

I don't think configuring these rules works at all.

Defining my rules like so...

{
  "rules": {
    "typescript/no-floating-promises": [
      "error",
      { "ignoreVoid": true, "ignoreIIFE": true }
    ],
    "typescript/no-misused-promises": [
      "error",
      {
        "checksVoidReturn": false,
        "checksConditionals": true
      }
    ]
  }
}

I am still getting errors about voided returns

[Boshen]

We'll need to redefine the schema.

[camc314]

To reduce the amount of data we are sending from oxlint -> tsgolint, we are going to switch around how we're storing this info.

Currently the object looks something like:

type Payload = {
    files: ConfigForFile[]
}
type ConfigForFile = {
    file_path: string
    rules: string
}

When linting vscode repo, with all type aware rules enabled, this causes us to pass in 6 712 400 bytes (6.7 MB) via stdin, and this size will only grow when we pass in rule configurations to tsgolint as well.

Since typical projects will be running the same set of rules on all files, we can re-structure the object to look like:

type Payload = {
    configs: Config[]
}
type Config = {
    file_paths: string[]
    rules: { name: string, config: any }[]
}

Which should reduce the duplication of passing in massive JSON objects.

[camchenry]

Total agree on changing the schema. A few additional thoughts on ways we could shrink the input even more possibly:

• Use integers for the rules instead of strings. All of the type aware rules could easily fit into a single byte (u8). We would just need to define an enum translation on the oxlint and tsgolint side. This would save quite a few bytes for each rule, especially if many rules are configured.
• Define a base path property of each config. Include the base directory of the tsconfig file for each directory, and then trim each path inside the config to be relative. If there are any paths outside of the base directory, leave it as absolute? Not sure that can happen or not. This would save lots of duplicate bytes in the common case where all paths have the same prefix.

[Sysix]

Not sure that can happen or not. This would save lots of duplicate bytes in the common case where all paths have the same prefix.

Are the file paths absolute?
oxlint has a cwd where the file searcher will start from. I think this is safe to strip the cwd and pass it into Payload.