chore: prefer type imports

[Shinigami92]

Description

Prefer type imports

Additional context

This forces to use always type imports. This improves TS compiled output and removes (in some cases) unnecessary empty imports.

---

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.

[userquin]

FYI: with typescript 4.5.* you can also use import { type XXX, YYY, ZZZ } from '....'

[Shinigami92]

FYI: with typescript 4.5.* you can also use import { type XXX, YYY, ZZZ } from '....'

I know, but not sure right now if this is necessary + if the lint rule support it already.
The current PR works right now 🙂

[userquin]

FYI: with typescript 4.5.* you can also use import { type XXX, YYY, ZZZ } from '....'

I know, but not sure right now if this is necessary + if the lint rule support it already. The current PR works right now 🙂

ok, here the link: https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-rc/#type-on-import-names

[antfu]

What's the benefit of forcing this tho?

To me, it was mainly to avoid accidentally introducing side-effects from the modules that you only need the types from. But if you are already imported some runtime from a module, the type specifier kinda lost the advantage.

I guess the new syntax in 4.5 will be better, but currently, it breaks many imports from one line to two, which kinda makes the code harder to read and maintain to me.

[Shinigami92]

Yes you are right that the TS 4.5 syntax could help, BUT I would like to use eslint fixer for that

The two lines are sometimes better cause they are then not wrapped cause of printWidth
Also the imports at the top are mostly not for read but auto organized

When TS 4.5 syntax is supported by @typescript-eslint we can switch to the option

[Shinigami92]

Tracking typescript-eslint/typescript-eslint#3950

[Shinigami92]

Tracking typescript-eslint/typescript-eslint#2769

[johnnyshankman]

TS keeps complaining about import.meta.env

Why was I linked here from #6194? What is the solve in vite2?

[johnnyshankman]

Was only able to solve with "types": ["webpack-env", "vite/client"], in my tsconfig? Can we like... put that somewhere? You guys closed all of these issues without explaining the solution at all.

https://vitejs.dev/guide/env-and-mode.html#intellisense-for-typescript

This could not be harder to find and does not explain well what the needs are. I dont even know what Intellisense is but I know I'm using TS.

[johnnyshankman]

https://stackoverflow.com/questions/66039933/typescript-types-for-import-meta-env

[ZeekDaGeek]

Here's what's happening:

By default when you use npm create vite@latest my-vue-app --template *-ts it creates a file called src/vite-env.d.ts. While cleaning up all of the files in src/ it ends up getting deleted.

Here's the original: https://github.com/vitejs/vite/blob/main/packages/create-vite/template-vanilla-ts/src/vite-env.d.ts
While this link is for the vanilla-ts template all of the *-ts templates look similar, check your own template to make sure.

Alternatively you can fix it by adding "vite/client" to your types compilerOptions inside of tsconfig.json. Eg:

{
  "compilerOptions": {
    "types": ["vite/client"],
  }
}

Make sure to leave any additional types intact for other LSP integrations.

For the react-ts template that would look like this:

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "types": ["vite/client"],
  },
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

If you've never used Vite before it's a very simple mistake to make, a lot of people seem to have the issue, and all of the issues seem to point to here.

Sorry for updating a dead post, closing resolved tickets sucks and results in information going in weird spots when they could instead go into the ticket that shows up on your first Google search.