Using mirage of versions above 0.1.35 fails to build and run

We are a team that is working on a Nuxt prototype and have been using mirage for this with TypeScript for about 2-4 weeks. Ever since version 0.1.36 was released then node have been unable to build and run our application. The only fix was reverting to an older version of mirage. One error can be seen below:

1:34 Module '"miragejs"' has no exported member 'JSONAPISerializer'.
  > 1 | import {Server, Model, Response, JSONAPISerializer} from 'miragejs'
      |                                  ^

My question is this: Have the way we should use mirage changed with the new typescript support? Is there any documentation to describe how we should use mirage with typescript?

mirage.ts:

import {Server, Model, Response, JSONAPISerializer} from 'miragejs'
import users from "./fixtures/users"
import contacts from "./fixtures/contacts"

export function makeServer(environment =  "development") {
    return new Server({
        environment,
        fixtures: {
            users,
            contacts
        },
        models: {
            user: Model,
            contact: Model,
            smsVerification: Model
        },
        serializers: {
            application: JSONAPISerializer
        },
...

In the above code, the JSONAPISerializer is not recognized as being available from miragejs and the schema do not seem to contain any of our fixtures (i.e. users for instance is currently an array of json objects). Below is (some of) the packages defined for our node setup:

package.json:

{
...
    "dependencies": {
        "axios": "0.19.2",
        "nuxt": "2.11.0",
        "ts-loader": "6.2.1",
        "typescript": "3.8.3",
        "vue": "2.6.11",
        ...
     },
    "devDependencies": {
        "@babel/core": "7.9.0",
        "@nuxt/typescript-build": "0.6.2",
        "@nuxtjs/eslint-config": "2.0.2",
        "@nuxtjs/eslint-module": "1.1.0",
        "@types/jest": "25.1.4",
        "@vue/cli-plugin-unit-jest": "4.3.0",
        "@vue/cli-service": "4.3.0",
        "@vue/test-utils": "1.0.0-beta.32",
        "babel-core": "7.0.0-bridge.0",
        "babel-eslint": "10.1.0",
        "babel-jest": "25.2.6",
        "eslint": "6.8.0",
        ...
        "jest": "25.2.7",
        "miragejs": "0.1.37",
        "ts-jest": "25.3.1",
        "vue-jest": "3.0.5"
      }
}

[dfreeman]

We have a few examples in our tests, but they are quite Ember.js related.

What part of those tests is Ember related? I could totally be missing something, but I wasn’t under the impression that anything with models, factories, or the schema object were unique to Ember 😄

const user = schema.users.findBy({ username: json.username });

Unfortunately, this kind of string-manipulation logic (“there’s a model called user, so the schema has a collection called users”) isn’t representable in TypeScript’s type system.

Fortunately, the schema itself also has methods that TypeScript can encode types for, so your lookup above can also be written:

schema.findBy('user', { username: json.username });

Right now, it doesn’t look like the routes callback to the Server constructor actually has the right type info for that call to typecheck, though. I’ll see if I can put together a PR to fix that.

[dfreeman]

@zoltan-nz making ServerConfig generic is one piece of the puzzle, but we also need to relate the type of its models and factories to its Registry type in the context of a new Server(...) call.

Unfortunately, because constructors can only accept the type parameters of the class itself, it’s not possible to do that without making the Server type much more complicated. I’ve been bouncing some ideas on that back and forth with Sam, and in the meantime I put together #406, which doesn’t directly fix this but does unblock having relationships work properly once it is fixed.