Regular Expression - improve on-hover notation for literal expressions

[BribeFromTheHive]

🔍 Search Terms

regex, regular expression, syntax highlighting

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I would like to be able to hover my mouse over a variable holding a regular expression and see the literal string or /expression/ that was used in its construction (if known).

📃 Motivating Example

This feature adds the ability to view the regular expression that went into a variable, meaning that you can abstract regular expressions away into separate files without losing the meaning behind what the regular expression represents. This is a quality of life improvement that does not solve the million problems that most regular expression examples look to solve, meaning that it won't parse or try to understand the context of the RegExp, but it will no longer disadvantage users who hoist their expressions rather than inline them.

💻 Use Cases

1. What do you want to use this for?

• For projects where regular expressions would be better served by being hoisted to a different file (like a shared module)

2. What shortcomings exist with current approaches?

• Current approaches require augmenting every regular expression with detailed comments, which is a lot of unnecessary boilerplate (which is more aligned with JSDoc rather than TypeScript) and can get messy when doing things like renaming capture groups and needing to update the comments accordingly.

3. What workarounds are you using in the meantime?

• I'll show you what I've done, which works well for string-literal based regular expressions, but requires converting ALL /forward slash/ regular expressions to be manually refactored to their string literal equivalents, which is very time consuming and shouldn't be necessary for the end user. Here's what I've developed to solve my own problem, but that still requires not using /notation/:

/**
 * A regular expression that remembers the string literals used in its creation.
 */
export interface TypedRegExp<S extends string, F extends string> extends RegExp {
    source: S;
    flags: F;
}

export const createTypedRegExpr = <T extends string, M extends string = ''>(
    stringExpr: T,
    flags?: M
) => new RegExp(stringExpr, flags) as TypedRegExp<T, M>;

[BribeFromTheHive]

As an additional example, this screenshot shows how it looks when using my workaround, which is "good enough":

But when mousing over a standard regex, I just see "RegExp", which is almost useless in its vagueness.

It would be super cool if Typescript could actually convert the on-hover tooltip info to raw /regexp/ syntax, but as long as we get "something" to improve linting support, I'd be happy.

Additionally, something that I coded for my own resource, might be too small to be its own NPM repository, but if someone stumbles upon this request via a search engine, this following solution helps to eliminate the vague nature of the "any[]" over-simplified solution to String.prototype.replace, which, from what I've seen, is among the more common complaints about regular expression awareness in TypeScript:

export type NamedReplacerFn = (
    group: Record<string, string | undefined>,
    wholeMatch: string,
    offset: number
) => string;

export type SimpleReplacerFn = (
    groups: (string | undefined)[],
    wholeMatch: string,
    offset: number
) => string;

declare global {
    interface String {
        // Breaks down the normal string.replace method to insert the named capture groups
        // as the first parameter. This allows easy object destructuring within parameters.
        replaceNamed: (regExp: RegExp, replacerFn: NamedReplacerFn) => string;

        //Places the capture groups into an array, which helps to enforce type safety rather than using 'any[]'.
        replaceArray: (regExp: RegExp, replacerFn: SimpleReplacerFn) => string;
    }
}

String.prototype.replaceArray = function (regExp, replacerFn) {
    return this.replace(regExp, (...args) => {
        return replacerFn(args.slice(1, -2), args[0], args.at(-2));
    });
};

String.prototype.replaceNamed = function (regExp, replacerFn) {
    return this.replace(regExp, (...args) =>
        replacerFn(args.at(-1), args[0], args.at(-3))
    );
};