feat: add basic character classes

[jaworek]

Summary

This PR implements whitespace, digit, word, and any character class.

Test plan

Passings tests

[mdjastrzebski]

1. since white space is constant, we could make it a global object instead of a function.
2. Just like other "components" this should be probably split into
   a) element builder (here static object):

export const whitespace = {
  type: `whitespace`
}

and b) a simple compile operation, placed in compileSingle fn:

function compileSingle(element: RegexElement): string {
  if (typeof element === 'string') {
    return element;
  }
  
  if (element.type === 'whitespace') {
    return "\\s";
  }

  // ...
}

You can even steamline it further by declaring something like:

const characterClasses = {
  whitespace: "\\s",
  digit: "\d",
  word: "\w",
  any: ".",
}

and then do something like

function compileSingle(element: RegexElement): string {
  if (typeof element === 'string') {
    return element;
  }
  
  const characterClass = characterClasses[element.type];
  if (characterClass !== undefined) {
    return characterClass
  }
  
  if (element.type === 'whitespace') {
    return "\\s";
  }

  // ...
}

[jaworek]

Sounds good to me :D

[jaworek]

I updated PR and added rest of basic character classes as it was trivial. Let me know if current solution is what you had in mind. :D

[okwasniewski]

I was thinking how this api should look like, and although this looks good I think it's not the best DX experience.

If someone has zero knowledge about Regex having one for example enum with Characters would be better. As user could leverage autocomplete Character.whitespace or Character.digit WDYT?

[mdjastrzebski]

@okwasniewski I think that common namespace enum for just character classes is not enough, as users will struggle with all other component imports (oneOrMore, buildRegex, range, etc). One way to solve it would be to recommend prefixed imports:

import * as re from "ts-regex-builder";

const regex = re.buildRegex(
  re.oneOrMore(
    re.whitespace)
  )
)

Slightly ugly, but so far this is the most autocompletion-friendly thing I have figured out.

@okwasniewski, @jaworek, maybe you have some alternative ideas on how we could improve autocompletion, API discovery, imports management.

[okwasniewski]

Why did you remove it?

[jaworek]

[jaworek]

In which case we'll hit last return? Based on the config type it seems that it will always hit first or second return.

[mdjastrzebski]

JetBrains voodoo 🤣

My take here would be to drop redundant checks if TS is happy.

However, should consider some more ergonomic util functions for verifying assumptions about received options. In another PR.

[mdjastrzebski]

Almost there! 🔥

[mdjastrzebski]

JetBrains voodoo 🤣

My take here would be to drop redundant checks if TS is happy.

However, should consider some more ergonomic util functions for verifying assumptions about received options. In another PR.

[mdjastrzebski]

If you add as const to character compiles, would that enable you to drop the ('children' in elements) check?

[jaworek]

Unfortunately no. TS does not like when string passed as a key is wider than what object keys are, even if you handle such case by checking for undefined.

Alternatively I can check if elements.type is one of the correct keys, but when I tried it before it was not narrowing elements.type after the if statement, so it required additional checks for elementCompiler, etc.

const isCharacterClassKey = (value: string): value is keyof typeof characterClasses => {
  return value in characterClasses;
};

if (isCharacterClassKey(elements.type)) {
    return characterClasses[elements.type];
}

[mdjastrzebski]

check current version, I've solved it

[mdjastrzebski]

I've rebased on main and did some type tweaks. Pls do reverse review @jaworek

[jaworek]

I've rebased on main and did some type tweaks. Pls do reverse review @jaworek

Thanks! LGTM 🚀