Adds CommonJS to regex/internals

[compulim]

Related to #29.

This is adding CJS/ESM to export regex/internals. attw looks good to me.

As regex already supports CommonJS. This pull request would improve platform support for using regex/internals (and transient dependents) in environments that doesn't fully support ESM. For example, Webpack 4, which is still commanding about 25.8% of Webpack weekly installations based on data from latest v4 vs. v5.

As regex is gaining popularity, packages that transiently depends on regex/internals may need this little lifts to get onboard the train. One such example is the very popular code syntax highlighter shiki, which has > 2M weekly downloads. It transiently depends on regex/internals.

regex is building block for great packages. Personally, as the package already support CommonJS, I think it makes sense to improve regex/internals support for broader platforms as well, including some popular but slowly deprecating platforms. It would help dependents to improve their build environment supports.

The other way to solve the problem would be embedding all packages down to regex via esbuild noExternal options. While this is an acceptable solution, it would hurt vulnerability patching process as the code is embedded deeply.

I hope you would consider this pull request.

Notes: barrel files at the root is required for Webpack 4 as it does not understand package.json/exports. It could be moved to another directory and copied to the root with the post-build script. I have tested this with a vanilla Webpack 4 + babel-loader setup.

[slevithan]

Thanks for the PR. Are you using regex/internals yourself, or just trying to help out?

Shiki (which you mentioned) is ESM-only so doesn't need this. And, in any case, oniguruma-to-es (which is where Shiki's indirect dependency for regex/internals is coming from) already includes a CJS bundle that doesn't need this change. There are currently no known consumers of regex/internals except oniguruma-to-es. It would be interesting if there were (it would imply regex libraries doing pretty advanced stuff), but I'm okay with requiring ESM for this specific, advanced, and rarely-needed export (it's only useful for tools that want to build on top of specific Regex+ internal capabilities; it is not useful for people who want to use Regex+ directly).

Essentially, I don't think the added complexity, file/build messiness, and future maintenance of this are worth the benefits, especially since I'm not sure there are any benefits, unless you have a specific use case in mind. Even then, I might ask you to build your own CJS bundle for the internals in your library, where you're trying to use it.

[slevithan]

Why does this point to src/regex.js -- was that intentional?