fix(types): correct import of types

[GrygrFlzr]

Description

Fixes #4002.

d.ts files are treated as an ambient module declarations only if they don't have any imports. If you provide an import line, it's now treated as a normal module file, not the global one, so augmenting modules definitions doesn't work.

• Michał Lytek from StackOverflow

Thus, the addition of imports in the client.d.ts in #3638:

import {
  ErrorPayload,
  FullReloadPayload,
  PrunePayload,
  UpdatePayload
} from 'types/hmrPayload'

Is improper and invalidates client.d.ts as an ambient declaration.

Instead, we have to import types this way:

(
  event: 'vite:beforeUpdate',
  cb: (payload: import('./types/hmrPayload').UpdatePayload) => void
): void

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

@GrygrFlzr for the rest of the types, we are duplicating the definitions instead of importing them. I am fine if this is a better approach and we start moving towards using imports, but if we plan to leave things as is, shouldn't we duplicate also these definitions to be consistent? Or is there something different from these ones in particular?

[GrygrFlzr]

As suggested, I've swapped to consistently importing in order to remove the duplicated types. CustomEventName has been extracted out into its own file. This also fixes a missing import.meta.env.SSR property in client.d.ts.

[IanVS]

I copied these changes into my node_modules, and my type errors have disappeared. Seems to indeed fix #4002. Thanks!