Leverage TypeScript 4.7 upgrade for deep type imports

[dummdidumm]

Describe the problem

Right now we have to do ambient module hacks to define a public API through hand-written d.ts files for deep imports like @svelte/kit/hooks .

Describe the proposed solution

TypeScript 4.5 will support the exports field of a package.json along with a special import for types: microsoft/TypeScript#33079 (comment)

This means we could do

"exports": {
  "hooks": {
    "import": "./hooks.index.js",
    "types": "./types/hooks.d.ts"
  }
} 

If we do this we require people to use a compatible version of TypeScript which would be breaking change, so it would need to happen before 1.0 ideally.

Alternatives considered

• Keep the hack as-is for now and change it in v2
• Add a post-build-script which copies handwritten types to a location like hooks/index.d.ts where TS should pick it up

Importance

would make my life easier

Additional Information

No response

[dummdidumm]

Having second thoughts if this is really a 1.0 issue in the sense that it blocks a 1.0 release. If we get to releasing 1.0 before TS 4.5 is out the door and VS Code includes it in its latest version, we could do it, but even then not all users might be on the latest version of VS Code immediately, which will result in quite some friction.

[dummdidumm]

TS 4.5 is out. We need to wait on Vite and ESBuild to update accordingly first and then do this and #2654 in one sweep.
Edit: Got excited too soon: TS reversed rolling out ESM support due to concerns: microsoft/TypeScript#46452 . This also affects the exports stuff.
Another edit after reading the issue: Seems they expect the ecosystem to prepare, meaning adding types entries to the package.json already, so maybe we should look into adding some kind of dual mode, supporting both.

[dummdidumm]

Removed this from the 1.0 milestone, a backwards-compatible solution should be preferred for now. TS 4.6 at the earliest might contain stable support (which is more than 2 months from now) and even then it's not set in stone that everything will work reliably.

[benmccann]

I sent a PR to upgrade to TypeScript 4.6: #4190. However, it looks like this feature is still only available in nightly (microsoft/TypeScript#33079 (comment)). We can check back in again for TypeScript 4.7

[dummdidumm]

TS 4.7 will probably have the new resolution but we will likely not enforce it on the user (yet?). I don't know if export maps and type resolution will work for non-nodenext, too. If not, we won't be changing this.

[benmccann]

We're on TypeScript 4.7 and have added a types field here: #2896

I don't know if we want to add types for each sub-export? I'm changing this to 1.0 milestone since it sounds like it'd be a breaking change and there's no other blockers. Feel free to close it if it's already done

[dummdidumm]

Not sure if we should do this in the near future. TypeScript ignores the package exports map if you don't opt in to the new module/moduleresolution (Node16 or NodeNext) - but if you do opt in to these, you are also required to adhere to the "always add explicit file endings" rules, so you need to write imports like import { foo } from './bar/index.js instead of import { foo } from './bar';

[benmccann]

Does this work with bundler? If so, then I think we could start doing this

[dummdidumm]

This is obsoleted by the the dts-buddy approach of having one big ambient module file, therefore closing right away - but yes, bundler would also enable this.