fix: fix arethetypesworking errors in all packages

[gobengo]

Motivation:

• The Types Are Wrong! #982

Learned While Devving

• The Types Are Wrong! #982 indicated 3 errors coming from atty. Here is how each error type was resolved
  1. ESM (dynamic import only) - this is more of a warning than an error. It's warning, rightly, that versions of node that only use CommonJS requires (e.g. require("@web3-storage/did-mailto")) won't be able to load these libraries. i.e. these libraries are "ESM-only" in that they only work on runtimes that can do ESM-style import(). By default, attw warns on this, but this PR configures attw to ignore instead (via .attw.json https://github.com/web3-storage/w3up/pull/1004/files#diff-a3be4137698f4bdc5777d3831fac4e67d11c102c5e57dd54906ff333cb551aff ).
  2. internal resolution error
     • Insight via https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/InternalResolutionError.md#declarations-and-javascript-match-but-are-not-checked-with-correct-settings

       This problem can occur with tsc alone if the library author compiles with --moduleResolution node (also known as node10) or bundler, especially in combination with a package.json that has "type": "module"

     • This attw error was resolved by this PR but this PR changing all packages tsconfig.json to use moduleResolution=NodeNext (not Node). To do that, many type imports had to change so the imported module identifier includes a file path suffix
  3. no types - Most of these were due to the relevant package having sub packabe submodule listed in package.json exports but without a corresponding js file existing (e.g. it was an old package submodule that has since been removed)

Also

• added an npm script attw to run attw for the package. Now can run attw for all packages like pnpm -r attw from monorepo root
• gitlab ci workflows for the two packages shown in The Types Are Wrong! #982 now run attw

[gobengo]

changing where this points to resolved some atty errors. When we do it this way and let typescript also write the type declaration files with all its defaults next to the source files, then when another tsc in a depending lib finds all this config, it'll be able to find the src,types,etc again.

There are some tricky bits here that I learned from https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseESM.md#common-causes

[alanshaw]

Can you update the npm published files so we don't include src in the root?

[gobengo]

@alanshaw #1012

[gobengo]

This is one of many small changes to ensure all imported module identifiers (e.g. type imports in comments like this) have a file suffix, which is required by tsc now that this PR enables moduleResolution=NodeNext for all tsc packages.

[gobengo]

This change inspired by
https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/64b1f489736bd48ebb4e3b72fb078b44437d59e0/docs/problems/InternalResolutionError.md

This problem can occur with tsc alone if the library author compiles with --moduleResolution node (also known as node10) or bundler, especially in combination with a package.json that has "type": "module"

and

Library authors should always compile/check with --module node16 --moduleResolution node16 or nodenext (note that module im

[travis]

Looks great! have a couple requests, and I'd feel a lot comfier if @alanshaw or @olizilla got a chance to take a look, but happy to see it merge as-is. Adding attw to the builds is 🚀 🎸 🆒 😎

[travis]

could you add a comment here justifying the ignore?

[gobengo]

I removed it! good catch. My local checker was in a weird state across my editor and local terminal and ci, but I think it'll work now e9882a4

[travis]

here too plz

[gobengo]

updated df5995b