Typescript enables Vue Single File Components (SFCs) to have a well-defined interface, such as knowing what prop names and types are allowed. Exciting!

However, you might want to test a component, and that's where the framework seems to have trouble. You have to import your typed Vue component from the .vue file into a Typescript file in order to test it.

Is there any mechanism that can be integrated into jest as a preset, or a loader or similar to facilitate imports from .vue files in test.ts files.

You can roll your own tooling to maintain redundant .d.ts files alongside the .vue source. An example is using the vue-tsc tool and a dedicated tsconfig.test.json to (re)create .d.ts files before every test run (linked below by Jeff Bowman). However, this is incredibly slow to re-build each time even in a small codebase. Also there is no obvious mechanism for this to be part of a jest pipeline (e.g. that could respect changes to edited source files as part of jest --watch within a modern TDD workflow)

By contrast for pure typescript, a preset like ts-jest provides integrated tooling for libraries AND tests to be written in typescript. No standalone build step is needed, no extra non-source files are strewn around the source tree, and changes to source files are immediately reflected within a jest --watch process.

Is there a jest-oriented toolchain that would permit a .vue file to be imported as a typed component into a Jest test written in typescript?

Take this example (jest) test.

// MyComponent.test.ts
import { mount } from '@vue/test-utils';
import MyComponent from './MyComponent.vue';

test("MyComponent click behaviour", () => {
      const wrapper = mount(MyComponent, {
        propsData: {
          message: 'Here is something to show to the user.',
        },
      });
      const label = wrapper.find('[class="my-component"]');
      await label.trigger('click');
      expect(wrapper.element).toMatchSnapshot();
})

Ideally this jest .test.ts file should be able to import a .vue SFC and benefit from the typings of the component declared in it.

A fallback approach would be any tooling integrated with jest which ensures that types are maintained when running e.g. jest --watch