test: add `vitest` for testing

[Zolyn]

See https://github.com/wheatjs/vite-plugin-vue-type-imports/pull/19#issuecomment-1203143020

Other changes

• Update dependencies to the latest version (including playground)
• Update eslint config and ignore patterns
• Update gitignore to ignore directory coverage
• Update tsconfig.json for better testing experience
• Update tsup.config.ts to remove some unnecessary fields
• Remove prettier and its configurations because it may conflict with antfu's eslint config (@antfu/eslint-config)
• Linting

NOTE: This PR contains multiple commits, so it is recommended to use Squash and merge.

[wheatjs]

Awesome, I was actually thinking about adding this the other day!

[Zolyn]

I made the structure of the test directory as follows:

test
├── common.test.ts // test file
├── fixtures
│   ├── common // category
│   │   ├── interface-extends-interface // scenario
│   │   │   └── no-reference // more detailed scenario
│   │   │       ├── index.ts // entry file (types)
│   │   ├── interface-without-reference
│   │   │   └── default
│   │   │       └── index.ts
│   │   └── redeclaration-of-types
│   │       └── default
│   │           └── index.ts
│   └── dynamic
│       └── interface-without-reference
│           └── default
│               ├── index.ts // the type file corresponding to the entry file
│               └── index.vue // entry file (code)
└── in-sfc.test.ts

Some explanations

Currently, I divided fixtures into two main categories:

Common

"Common" means that all tests under this category are based on the same code, which corresponds to the scenario "use the imported type directly". Therefore, only type files are included under this category.

function generateCode(path: string): string {
    return `<script lang="ts" setup>
import { Props } from '${path}'
defineProps<Props>()
</script>
`
}

Dynamic

"Dynamic" means that most of the tests under this category are based on different code. The most common scenario is "use the imported type indirectly". We need to read the content of the files and transform them.

Entry file

Each detailed scenario can have multiple entry files to add more constraints.

We will test the entry files with different options, which means that each entry file has multiple tests.

About the name of the tests

Actually, I'm talking about the export name of each test in the snapshot file.

I imagine two ways of naming it.

1

Category > Scenario > Detailed scenario > entry file (options)

Example:

Common > Interface extends interface > No reference > index.ts (normal)

NOTE: The name of scenarios will be normalized. (e.g. interface-extends-interface > Interface extends interface)

2

Category > relative path of entry file > options

Example:

Common > interface-extends-interface/no-reference/index.ts > normal

Maybe I need to implement it and look at the output of running tests before I can decide which way to go. :P

My personal opinion on this

• All tests are based on the function transform, we may need to test other functions in the future.
• At the moment we don't do component testing because I have tried to do so and found that it only gets the name of each prop of the component and not the type of each prop.

I need suggestions (either it's naming, or whatever) to improve it before I implement it.

[wheatjs]

I don't think component testing will be necessary. We are mostly just doing basic transforms, so as long as we inspect that output after our transform and make sure everything is correct that should be good enough. Also component testing can be pretty complicated and heavy, so I think leaving it as vitest is well enough.

[Zolyn]

I don't think component testing will be necessary. We are mostly just doing basic transforms, so as long as we inspect that output after our transform and make sure everything is correct that should be good enough. Also component testing can be pretty complicated and heavy, so I think leaving it as vitest is well enough.

That's what I said. :D

I've also updated the comment, do you have any suggestions on it?

[Zolyn]

This is the error output of the two naming styles when the test encounters an error.

Which one do you think is better? If you have a better solution, feel free to suggest. :D

[wheatjs]

Hmm personally I find the first one a bit easier to read.

[Zolyn]

@wheatjs Done.

PR description is also updated.