Declared types don't allow features of existing language definitions

[jsharkey13]

Describe the issue/behavior that seems buggy

I am attempting to declare and register a new language definition for an internal pseudolanguage (aimed at students, and very simplistic), but doing so in TypeScript and not plain JS. I am using 11.1.0.
I declare the new rules in a function with the type LanguageFn, and am attempting to add highlighting to function definition using an example copied from languages/javascript.js. There are examples which use similar config in Java and in C++ so I assumed this was a well-supported feature.

However, this won't compile because the ModeDetails interface expects the match property to be RegExp | string and does not allow an array of these. The documentation for match does say "type: regexp or array of regexp".

If I // @ts-ignore the whole function, then it does work and correctly highlight each section with the right class applied, so this is just an issue with the declared types.

Sample Code or Instructions to Reproduce

A minimal TypeScript example would be (slimmed down to the absolute minumum from the real JavaScript language definition referenced above):

import {LanguageFn} from "highlight.js";

const myLanguageRules: LanguageFn = function(_hljs) {
  return {
    name: 'myLanguage',
    contains: [
      {
        match: [
          /function/,
          /\s+/,
          /[a-z][A-Z]/,    // avoid using hljs.IDENT_RE for this example
          /(?=\s*\()/
        ],
        scope: {           // swap deprecated "className" to "scope" to avoid another type error
          1: "keyword",
          3: "title.function"
        },
      }
    ]
  }
};

This has the type error described above for match (and would have a type error on className if I had not swapped it to scope for version 11 compatibility).

Expected behavior

Since the example comes basically directly from one of the provided language definitions, I expected it to be allowed by the type definitions.

I think changing the ModeDetails interface to allow this case (if it is indeed valid!) is not too difficult and strictly an expansion of what is already allowed:

interface ModeDetails {
    // ...
    match?: RegExp | string | (RegExp | string)[]
    // ...
}

(leaving out all the other properties of ModeDetails that are fine).

Are the types written by hand? If so I can submit a PR, although it is a trivial copy and paste job from the above code block if this is the right approach.

[joshgoebel]

Are the types written by hand?

Yes.

If so I can submit a PR

Thanks, but I'll take a pass at this since this also applies to begin, end, etc, not just match... I'll ping you on the PR so you can take a glance.

[joshgoebel]

Closed via #3274.