refactor(types): simplify type exports

[bluwy]

Description

This follows up on #9966. (Sorry for the wall of text)

---

Reason for change

1. The new exported vite/client/types is confusing with vite and vite/client.

For example, you can import HMRPayload in both vite/client/types and vite. (I think the latter should only)

2. vite/import-meta feels very specific.

I'm discussing with @Princesseuh which maybe we can try to use vite/client if possible. I think we can remove vite/import-meta.

3. Hovering over import.meta gives ImportMeta_2 due to bundling.

I feel like this may bring a confusing experience for some people, and we should try sticking back to ImportMeta

4. Defining the CustomEventMap twice can be avoidable.

We need to deduplicate CustomEventMap so users only have to define once.

---

PR changes

1. Move src/types/ back to types/. Move src/dep-types/ to src/types/

I'll explain why I moved back to types/ below. But renaming dep-types to types is mainly a small annoyance i find of the directory showing

src
- client
- dep-types <-- between client/node
- node

2. All types in types/ are deduplicated (aka shared between client and node types)

This is done by making a post patch to the types in postPatchTypes.ts. Rewriting imports of types/* -> ../../types/*.

3. Fix ImportMeta_2, and remove vite/client/types and vite/import-meta

This one is tricky and is the main reason I move src/types/ back to types/. We need to define the ImportMeta manually to avoid the issue, but I find bundling the client types getting in the way, so I went back to the structure before.

I also don't see much usecase for vite/client/types (initially I wanted to rename this as vite/shared). But all types can be imported from vite instead, so I remove it to prevent duplication.

---

To be deprecated

• types/<dep> (types/importGlob, types/customEvent etc are fine but should be avoided unless documented)

Note: I did not deprecated types/importGlob which initially is superseded by vite/client/types due to the above reasons.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[sapphi-red]

Awesome!

Downsides of doing this that I could think are:

1. we won't be able to use api-extractor features in packages/vite/types (e.g. removing @internal properties).
2. typescript will show error when
   • this condition is met (related: vite config files can't be compiled without dom types #9813)
     • import { HMRPayload } from 'vite' (and other types) is imported
     • @types/node is not referenced
     • skipLibCheck: false
   • this could be workarounded by either
     • using import { HMRPayload } from 'vite/types/hmrPayload' that is not documented
     • add @types/node (node globals is not accessible from client code though)
     • skipLibCheck: true (not ideal)
3. the opposite of above (vite config files can't be compiled without dom types #9813)

(sorry that I forgot about 2 and 3 when discussing before)

That said, I think this is nicer than mine.

I suppose 1 is acceptable. For 2 and 3, maybe we could still have something like vite/client/types that will be included in exports?

[bluwy]

Thanks for the review!

Yeah no1 had always felt like an odd feature from api-extractor, but I think it'd be fine too.

Re no2 and 3, I think requiring @types/node is fair especially if they're planning to compile with tsc. I'd usually lean towards skipLibCheck: true too (personal preference 😬 )

I don't understand how exporting vite/client/types would solve #9813 though. IIRC it will still cause the issue. Can you elaborate on that?

[sapphi-red]

Re no2 and 3, I think requiring @types/node is fair especially if they're planning to compile with tsc. I'd usually lean towards skipLibCheck: true too (personal preference 😬 )

This is a reproduction of no2.
Since node related types are used in vite/node/index.d.ts, @types/node needs to be installed. Also if it's installed, it's always referenced (because vite/node/index.d.ts includes /// <reference types="node" />, it seems this can't be avoided by using compilerOptions.types). So when vite is imported, process will be shown as if it is declared.

I don't understand how exporting vite/client/types would solve #9813 though. IIRC it will still cause the issue. Can you elaborate on that?

If vite/client/types doesn't include node related types and doesn't depend on vite/node/index.d.ts, @types/node won't be referenced and won't be needed. So process won't be shown as if it is declared.

[bluwy]

Thanks for the explanation! I'm starting to understand the issue now. So if someone wants to import a type that doesn't also bring in node types, they can import from vite/client/types instead. Was confused as #9813 mentions dom types.

I guess my thoughts are:

1. Not everyone knows when to import from vite or vite/client/types.
2. Maybe they don't mind node types in client code.

But if we want to support this, I'd propose exporting via vite/shared 🤔 and we can bundle up the types within types/ (besides importMeta). I think it might be useful to support this, but I'm not sure the usecases out there that requires this.

Perhaps we can tackle this with a separate PR, but I'm also happy to implement something at the meantime too.

[sapphi-red]

Was confused as #9813 mentions dom types.

If we removed importGlob related types from vite/node/index.d.ts, we could solve #9813 (though we still have the error coming from esbuild's type def).
So we could solve #9813 (Importing vite/node/index.d.ts without adding DOM to tsconfig.compilerOptions.lib) and the opposite (what I said in the previous comment; importing client related types without node types).

1. Not everyone knows when to import from vite or vite/client/types.

Yeah, I agree it's difficult to tell people about this.

I'd propose exporting via vite/shared 🤔

types/importMeta needs to be externalized from vite/shared to avoid referring dom types.

Perhaps we can tackle this with a separate PR, but I'm also happy to implement something at the meantime too.

I don't have a good idea so I'm fine for now with this implementation. 🙂

[bluwy]

Merging with approval from @patak-dev