feat!: Dual-Support ESM & CJS

[danielbankhead]

Notable Changes

• Created split TS Configs with the default tsconfig.json defaulting to preserve ('esm').
• Added a basic package.json in build/esm so that all .jss there are loaded as ESM
• Greatly improved build times by removing the gts clean step before compilation and using tsc -b
  • Works well with gts v7's composite flag:
    • feat!: Set composite: true in tsconfig-google.json google/gts#899
    • Documentation: https://www.typescriptlang.org/tsconfig/#composite
• Renamed the bare relatively imports (e.g. ./path -> ./path.js) and fixed the directory imports (/ -> /index.js)
• Refactored the system-tests to use pack-n-play
  • The integration tests uses a local server for optimal testing; no more flaky external server

🦕

[sofisl]

I think my only concern with not using babel is that we have some unique plugins we wrote for additional functionality. I'm also concerned that if there's an error during compilation (or installation or whatever), the post-compile script won't run and then the library would fail. Seems safer to just convert those files to .cjs but I'm curious why you're interested in getting rid of babel.

[danielbankhead]

@sofisl With this strategy we can avoid babel and its added complexity of maintaining it. Are there specific features we need here that are not present?

that if there's an error during compilation (or installation or whatever), the post-compile script won't run and then the library would fail

I'm not sure I understand - if the compilation fails then library is already broken

Seems safer to just convert those files to .cjs

Unfortunately there are some gotchas with this approach; notably with renaming imports referencing these files. npm natively supports nested package.jsons and node respects the nearest package.json's type field, as outlined here:

• https://nodejs.org/api/packages.html#dual-commonjses-module-packages

Between the time the original doc was written and today the space has improved and simplified a ton.

[generated-files-bot]

Warning: This pull request is touching the following templated files:

• README.md - README.md is managed by synthtool. However, a partials file can be used to update the README, e.g.: https://github.com/googleapis/nodejs-storage/blob/main/.readme-partials.yaml

[sofisl]

• We have three plugins for our babel extension that replace __dirname, esmock, and we toggle an ESM flag variable. Seems like this library doesn't need it but if we do need to add these features before they're introduced in node, we'd need to rely on these plugins.

• You're right that if there's a failure in installation we probably have another problem anyways. My larger point is that the library doesn't work without also adding the package.json, so I don't think that should be a separate step in the typescript configuration. A simple fix would just be to add it to the end of the script, tsc -b ./tsconfig.json ./tsconfig.cjs.json && node utils/enable-esm.mjs

• FWIW, babel does take care of renaming the extensions wherever it imports.

I'm down to try it once we move the node step into compilation (vs. postcompile).

[sofisl]

Please combine the compile & postcompile step.