Open BribeFromTheHive opened 4 weeks ago
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))
);
};
π Search Terms
regex, regular expression, syntax highlighting
β Viability Checklist
β 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
What do you want to use this for?
What shortcomings exist with current approaches?
What workarounds are you using in the meantime?
/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/
: