feat: use a common tsconfig for the monorepo

[alexforsyth]

Issue #, if available:
#1026
Internal: JS-1866

Description of changes:

1. Created a root tsconfig.json and root tsconfig.cjs.json and tsconfig.es.json.
2. Each package extends the root tsconfig.cjs.json and root tsconfig.es.json in their local version. Those are themselves built from the historical tsconfig.json + tsconfig.test.json. The previous packages/*/tsconfig.json and packages/*/tsconfig.test.json have been removed.
3. Each package also now generates two builds, one common (cjs) in ./build and one esnext (es) in ./build-es. Packages have also been updated to provide a build:es and a build:cjs command.
4. Because we are now generating two builds the time to build should approximately double. This should not be too bad, as build time was greatly reduced in the previous PR: chore: faster build time #1285

FAQ:

1. Why not have each package have its own tsconfig? Its been a huge pain and contributes to non standard packages if they do not all adhere to the same typescript standards. We've chosen to have a rot tsconfig.
2. Okay, but why get rid of tsconfig in each package? Vscode looks at the closest tsconfig.json in the tree. In order for vscode to profile the repo correctly and code competition to work well, we need to have vscode profile stuff from the root, that means we need to keep the tsconfig there and remove it from closer places in the code tree.
3. It looks like a lot of the packages share many attributes in their tsconfig.(cjs|es).json, is it possible to pull those options out? Yes - there are tons of shared options, but not too many that are in each and every single package. I'll be making some nice updates in future PRs that will enforce things like "noUnusedParameters": true, everywhere but to keep this PR reasonable i've chosen not to include them here.
4. I see these changes do not apply to ./clients Correct. We cannot currently provide a common tsconfig for the generated clients. Smithy generates the tsconfig for us and does not provide a way to modify that tsconfig as part of generation. We also do not want smithy to explicitly extend a higher level tsconfig as that breaks encapsulation.

Experimental branch reference:
#1279

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

Merging #1297 into master will increase coverage by 16.66%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #1297       +/-   ##
===========================================
+ Coverage   73.04%   89.70%   +16.66%     
===========================================
  Files         287      151      -136     
  Lines       12730     3129     -9601     
  Branches     2922      576     -2346     
===========================================
- Hits         9299     2807     -6492     
+ Misses       3431      322     -3109     

Impacted Files	Coverage Δ
...es/node-http-handler/src/stream-collector/index.ts	15.38% <0.00%> (-84.62%)	⬇️
...ode-http-handler/src/stream-collector/collector.ts	57.14% <0.00%> (-42.86%)	⬇️
...ventstream-serde-universal/src/getChunkedStream.ts	94.11% <0.00%> (-0.12%)	⬇️
packages/hash-node/src/index.ts	100.00% <0.00%> (ø)
packages/region-provider/src/fromEnv.ts	100.00% <0.00%> (ø)
packages/signature-v4/src/SignatureV4.ts	100.00% <0.00%> (ø)
packages/property-provider/src/memoize.ts	100.00% <0.00%> (ø)
packages/signature-v4/src/cloneRequest.ts	100.00% <0.00%> (ø)
packages/signature-v4/src/getPayloadHash.ts	100.00% <0.00%> (ø)
packages/credential-provider-node/src/index.ts	100.00% <0.00%> (ø)
... and 164 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a6e304...3ff565a. Read the comment docs.

[alexforsyth]

@trivikr @AllanFly120 since this is my first major commit and it could cause some problems if I missed something, can you checkout the branch and make sure everything works and is solid on your local?

[trivikr]

Verified that browsing across dependencies in packages/* is possible without building them

Screen recording

[trivikr]

This PR needs rebase to include karma-credential-loader added in #1296

[trivikr]

One minor comment for removing build and build-es.

Also, it looks like karma-credential-loader is not rebased from master:

• https://github.com/aws/aws-sdk-js-v3/tree/aforsyth/root-tsconfig/packages
• https://github.com/aws/aws-sdk-js-v3/tree/master/packages

The changes would be required in karma-credential-loader too.

[alexforsyth]

One minor comment for removing build and build-es.

Also, it looks like karma-credential-loader is not rebased from master:

• https://github.com/aws/aws-sdk-js-v3/tree/aforsyth/root-tsconfig/packages
• https://github.com/aws/aws-sdk-js-v3/tree/master/packages

The changes would be required in karma-credential-loader too.

All done. My rebase screwed up so ended up just doing it in a merge. karma-credential-loader has changes propagated

[AllanZhengYP]

I'm fine if you uncomment it.😊

[alexforsyth]

We can't uncomment without massive changes across the repo. Lets address this in a followup

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.