How to use TypeScript with Vue.js

How to use TypeScript with Vue.js

In this artilce, you'll learn how to use TypeScript with Vue.js

inb4: This is not another “setting up” a new project with Vue and TypeScript tutorial. Let’s do some deep dive into more complex topics!

typescript is awesome. Vue is awesome. No doubt, that a lot of people try to bundle them together. But, due to different reasons, it is hard to really type your Vue app. Let’s find out what are the problems and what can be done to solve them (or at least minimize the impact).


We have this wonderful template with Nuxt, Vue, Vuex, and jest fully typed. Just install it and everything will be covered for you. Go to the docs to learn more.

And as I said I am not going to guide you through the basic setup for three reasons:

  1. There are a lot of existing tutorials about it
  2. There are a lot of tools to get started with a single click like Nuxt and vue-cli with typescript plugin
  3. We already have [wemake-vue-template]( where every bit of setup that I going to talk about is already covered
Component typings

The first broken expectation when you start to work with Vue and typescript and after you have already typed your class components is that `` and `

I have made two typos here: `{{ usr }}` instead of `{{ user }}` and `$style.headr` instead of `$style.header`. Will `typescript` save me from these errors? Nope, it won’t.

What can be done to fix it? Well, there are several hacks.

### Typing the template

One can use `Vetur` with `vetur.experimental.templateInterpolationService` option to type-check your templates. Yes, this is only an editor-based check and it cannot be used inside the CI yet. But, `Vetur` team is working hard to provide a [CLI]( to allow this. Track [the original issue]( in case you are interested.

![TypeScript with Vue.js](

The second option is two write snapshot tests with `jest`. It will catch a lot of template-based errors. And it is quite cheap in the maintenance.

So, the combination of these two tools provides you a nice Developer Experience with fast feedback and a reliable way to catch errors inside the CI.

### Typing styles

Typing `css-module`s is also covered by several external tools:

*   [typings-for-css-modules-loader](
*   [css-modules-typescript-loader](

The main idea of these tools is to fetch `css-module`s and then create `.d.ts` declaration files out of them. Then your styles will be fully typed. It is still not implemented for `Nuxt` or `Vue`, but you can tract [this issue]( for progress.

However, I don’t personally use any of these tools in my projects. They might be useful for projects with large code bases and a lot of styles, but I am fine with just snapshots.

Styleguides with visual regression tests also help a lot. `[@storybook/addon-storyshots](` is a nice example of this technique.

## [Vuex](

The next big thing is `Vuex`. It has some built-in by-design complexity for typing:

const result: Promise = this.$store.dispatch('action_name', { payload: 1 })

The problem is that `'action_name'` might no exist, take other arguments, or return a different type. That’s not something you expect for a fully-typed app.

What are the existing solutions?

### vuex-class

`[vuex-class](` is a set of decorators to allow easy access from your class-based components to the `Vuex` internals.

But, it [is not typed safe]( since it cannot interfere with the types of state, getters, mutations, and actions.

![TypeScript with Vue.js](

Of course, you can manually annotate types of properties.

![TypeScript with Vue.js](

But what are you going to do when the real type of your state, getters, mutations, or actions will change? You will have a hidden type mismatch.

### vuex-simple

That’s where `vuex-simple` helps us. It actually offers a completely different way to write your `Vuex` code and that’s what makes it type safe. Let’s have a look:

import { Action, Mutation, State, Getter } from 'vuex-simple'

class MyStore {

// State

public comments: CommentType[] = []

// Getters

public get hasComments (): boolean {
return Boolean(this.comments && this.comments.length > 0)

// Mutations

public setComments (payload: CommentType[]): void {
this.comments = updatedComments

// Actions

public async fetchComments (): Promise {
// Calling some API:
const commentsList = await api.fetchComments()
this.setComments(commentsList) // typed mutation
return commentsList

Later this typed module can be registered inside your `Vuex` like so:

import Vue from 'vue'
import Vuex from 'vuex'
import { createVuexStore } from 'vuex-simple'

import { MyStore } from './store'


// Creates our typed module instance:
const instance = new MyStore()

// Returns valid Vuex.Store instance:
export default createVuexStore(instance)

Now we have a 100% native `Vuex.Store` instance and all the type information bundled with it. To use this typed store in the component we can write just one line of code:

import Vue from 'vue'
import Component from 'nuxt-class-component'
import { useStore } from 'vuex-simple'

import MyStore from './store'

export default class MyComponent extends Vue {
// That's all we need!
typedStore: MyStore = useStore(this.$store)

// Demo: will be typed as Comment[]:
comments = typedStore.comments

Now we have typed `Vuex` that can be safely used inside our project. When we change something inside our store definition it is automatically reflected to the components that use this store. If something fails - we know it as soon as possible.

There are also different libraries that do the same but have different API. Choose what suits you best.

## [API calls](

When we have `Vuex` correctly setup, we need to fill it with data. Let’s have a look at our action definition again:

public async fetchComments (): Promise {
// Calling some API:
const commentsList = await api.fetchComments()
// ...
return commentsList

How can we know that it will really return a list of `CommentType` and not a single `number` or a bunch of `AuthorType` instances?

We cannot control the server. And the server might actually break the contract. Or we can simply pass the wrong `api` instance, make a typo in the URL, or whatever.

How can we be safe? We can use runtime typing! Let me introduce `[io-ts](` to you:

import * as ts from 'io-ts'

export const Comment = ts.type({
'id': ts.number,
'body': ts.string,
'email': ts.string,

// Static TypeScript type, that can be used as a regular type:
export type CommentType = ts.TypeOf

What do we do here?

1.  We define an instance of `ts.type` with fields that we need to be checked in runtime when we receive a response from server
2.  We define a static type to be used in annotation without any extra boilerplate

And later we can use it our `api` calls:

import * as ts from 'io-ts'
import * as tPromise from 'io-ts-promise'

public async fetchComments (): Promise {
const response = await axios.get('comments')
return tPromise.decode(ts.array(Comment),

With the help of `[io-ts-promise](`, we can return a `Promise` in a failed state if the response from server does not match a `ts.array(Comment)` type. It really works like a validation.

.then((data) => /* ... /
Happens with both request failure and incorrect response type */)

Moreover, return type annotation is in sync with the `.decode` method. And you cannot put random nonsense there:

![How to use TypeScript](

With the combination of runtime and static checks, we can be sure that our requests won’t fail because of the type mismatch. But, to be 100% sure that everything works, I would recommend using contract-based testing: have a look at `[pact](` as an example. And monitor your app with `Sentry`.

## [Vue Router](

The next problem is that `this.$router.push({ name: 'wrong!' })` does not work the way we want to.

I would say that it would be ideal to be warned by the compiler that we are routing to the wrong direction and this route does not exist. But, it is not possible. And not much can be done: there are a lot of dynamic routes, regex, fallbacks, permissions, etc that can eventually break. The only option is to test each `this.$router` call in your app.

## vue-test-utils

Speaking about tests I do not have any excuses not to mention `@vue/test-utils` that also has some problems with typing.

When we will try to test our new shiny component with `typedStore` property, we will find out that we actually cannot do that according to the `typescript`:

![How to use TypeScript](

Why does this happen? It happens because `mount()` call does not know anything about your component’s type, because all components have a `VueConstructor` type by default:

![How to use TypeScript](

That’s where all the problems come from. What can be done? You can use `[vuetype](` to produce `YouComponent.vue.d.ts` typings that will tell your tests the exact type of the mounted component.

You can also track [this issue]( for the progress.

But, I don’t like this idea. These are tests, they can fail. No big deal. That’s why I stick to `(wrapper.vm as any).whatever` approach. This saves me quite a lot of time to write tests. But spoils Developer Experience a little bit.

Make your own decision here:

*   Use `vuetype` all the way
*   Partially apply it to the most important components with the biggest amount of tests and update it regularly
*   Use `any` as a fallback

## Conclusion

The average level of `typescript` support in `Vue` ecosystem increased over the last couple of years:

*   `Nuxt` firstly introduced `nuxt-ts` and now ships `ts` builds by default
*   `[email protected]` will have improved `typescript` support
*   More 3rd-party apps and plugins will provide type definitions

But, it is production ready at the moment. These are just things to improve! Writing type-safe `Vue` code really improves your Developer Experience and allows you to focus on the important stuff while leaving the heavy-lifting to the compiler.

What are your favorite hacks and tools to type `Vue` apps? Let’s discuss it in the comment section.

Why You Should Use TypeScript With Vue.js

Why You Should Use TypeScript With Vue.js

Why You Should Use TypeScript With Vue.js: It’s easier to write good TypeScript code than good JavaScript code

Why Use TypeScript

Statically typed languages are awesome. Consider the following example in plain JavaScript.

function getBooks(query, user) {
  let books = []
  // Retrieve books from API
  return books

This code is hard to understand for the following reasons.

  • There is no way to know what type the query and user parameters need to be. The user parameter could be a user object or a string denoting the user’s name — or something else, for that matter.
  • There is no way to know what data type the function returns. It returns an array, but is it an array of strings, objects, or book ids?

The only way to communicate this in plain JavaScript is via comments.

Let’s rewrite this code using TypeScript.

class Book {
  id!: number
  user_id!: number

  title: string

function getBooks(query: string, user: number): Book[] {
    let books : Book[] = [];

    // Retrieve books from API

    return books;


First, I define a class Book, with each book having an id, a user_id, and a title.

Next, I specify that the query parameter is a string and the user parameter a number. The function returns an array of books.

Because I specified this, my IDE can do some amazing autocompletes.

Hopefully, you are convinced that TypeScript is amazing. Let's dive into how to set up a Vue TypeScript project!

Create the Vue Project

To create the project, I’m going to use the Vue CLI. This is the official command-line interface that makes creating a new Vue project a whole lot easier.

npm install -g @vue/cli

I can now create the project with a simple command.

vue create my-project-name

Make sure to select “Manually select features” in the prompt.

For this project, I will only use the TypeScript and Router features.

Class style component syntax

When asked if I want to use class-style component syntax, I select yes.

Normally each Vue component will export a JavaScript object, like so:

  export default {
    props: {
      msg: String,
    data() { 
      return {
        title: "Hello World!",

However, when using the class style component syntax, each Vue component will export a class instead of an object. The HelloWorld component would then look like this:

<script lang="ts">
  import { Component, Prop, Vue } from 'vue-property-decorator';
  export default class HelloWorld extends Vue {
    msg!: string
    title:string = "Hello World"

Personally, I find this syntax much cleaner.

View Your Vue App

Select the default values for all other settings. After the setup wizard is done, run npm run serve to start the development server. Head over to localhost:8080 and view the Vue app!

That’s all there is to it. Thanks to the Vue CLI, everything works out of the box. I still have nightmares about debugging my Webpack config file, so the CLI is a genuine lifesaver.

What are the differences between the various JavaScript frameworks? E.g. Vue.js, Angular.js, React.js

What are the differences? Do they each have specific use contexts?

What are the differences? Do they each have specific use contexts?