Add types field to exports to resolve node16 and nodenext typescript module resolution

[balupton]

Several of the Bevry projects have users trying to use this new module resolution in TypeScript >= 4.7. Bevry hasn't encountered this yet as we just use node as the module resolution.

The solution to this is to have boundation generate a types export, this will resolve it on all Bevry projects and prevent reversion of manual changes from these PRs:

• fix(typescript): add types field in exports to fix declaration file bug for TS >= 4.7 w/ moduleResolution: 'nodenext' filedirname#223
• Add Typing of returns getmac#312
• Include types in the exports entry of the package.json envfile#210
• Reference types in export declaration get-current-line#187
• Add types resolutions to package.json exports field to support NodeNext/Node16 module resolution. get-current-line#196

And these issues:

• TypeScript error when using "moduleResolution": "node16" istextorbinary#270
• Could not find a declaration file for module 'filedirname' filedirname#224
• Use in a Node.js Typescript project -- Could not find a declaration file for module 'getmac' getmac#325
• Could not find a declaration file for module 'envfile' (TS7016) envfile#214
• Typescript's new moduleResolution breaks errlop's typing errlop#196

[balupton]

This is in my current batch of work, and I'll tackle it this week.

Sorry it took 18 months from the first report! Thanks to my GitHub Sponsors, I've now been able to afford this month to work on my javascript projects again. The more sponsors, the more I can support my projects, and the smaller the delay in fixes.

[balupton]

The reason Bevry never encountered this issue is twofold:

1. We use "moduleResolution": "Node" instead of NodeNext/Node16

2. We use "maxNodeModuleJsDepth": 5 however anything 2 or higher will do, even with NodeNext and Node16

I'm now testing the module.exports[...][types] suggestion.

[balupton]

Okay, so module.exports[...][types] cannot be a directory (same as index.cjs types annotation), unlike package.json:types which should be a directory. It does resolve the issue.

To make this happen properly I think I'll make an edition for the types, that way it's entry can be easily fetched.

The code has also reemerged the issue of deno/bun/worker exports. Currently that is handled via entry points, however generating exports for them I believe was something we did. I will need to look into this tomorrow.

[balupton]

The change has been verified on the typechecker package and its consumer ambi.

I'll now run the new boundation release on all the bevry packages, and it'll roll out over the coming days.