• the previous assumption that ESM users will always import the ESM
  build doesn't actually hold up in practice due to various limitations
  in Node and testing and the prevalence of transpiling in general

  • even if one uses mostly ESM, many tools will require and use
    the CJS build, and this option would break compatibility

• without esModule set, CJS users would be unable to use the default
  export of any library built with tsdx

  • and this was not documented, meaning it would cause unintended
    breaking changes in libraries that use default exports and try to
    adopt tsdx
  • it would also break compatibility with certain tooling

• so, instead of always setting rollup's esModule to false and
  potentially causing unintended consequences, respect the user's
  esModuleInterop config as set in their tsconfig, but default to
  false

Fixes #165 according to my suggestion in #165 (comment) . Mine and other folk's comments in that issue give more details about the compatibility and adoption issues that drive this PR. Ultimately, I believe this is a bugfix as the current behavior causes unintended consequences and because default exports are already output, just not with __esModule in CJS builds.

Have tested this successfully locally. All it does is, if esModuleInterop is set to true in tsconfig.json, will add a line of code to the CJS output as such:

Object.defineProperty(exports, '__esModule', { value: true });

As I mentioned in #165 (comment), everything else is the same as before, as ESM builds already output export default and CJS builds already output exports.default. __esModule is just a hint for transpilers to use .default when transpiling default imports to CJS.