feat: dual build to emit both commonJS and ESM to maximize compatibility

[NielsJPeschel]

Proposed changes

Modify package.json, tsconfig.json, as well as create tsconfig.es5.json to create both an es5 as well as an es6 build. This will simultaneously support CommonJS as well ES modules.

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

[NielsJPeschel]

@nthurow These changes make the build come together - commonJS projects will reference "main" whereas ESM projects refer to "module"

[nthurow]

But the "module" field isn't official, it's not even really documented anywhere. The "exports" field (along with the "require" and "import" conditions) is the official way to handle a dual build. So that's why what I'm thinking is, can we leave the "main" field here but add back the "exports" field (and make sure to include both "require" and "import" conditions)? The "main" field might solve some of the legacy issues that we are encountering with the SCL and tst-scl, and the "exports" field should still enable the dual-build.

[nthurow]

Can we leave "main" but remove "module"? "exports" is the preferred way to indicate which files can be imported, and "main" is the legacy fallback option (which is still supported). "module" was never officially part of the Node/NPM package.json spec and is just another unofficial field that some bundlers like Webpack recognize.

[nthurow]

Can we use one tsconfig as the base and have it extend the other?

[nthurow]

@NielsJPeschel per our discussion, I opened #32, which should resolve the issues related to certain applications not being able to locate the types for @optum/react-hooks. This should resolve our conversation around utilizing "main", "module", and "exports".

Once that PR is merged we can rebase this one onto main and have a further discussion on whether we want to go all-in on ESM and do it the "right way" (aka follow all of the Node requirements).