Adding chimp 3 to an existing Application

This article is based on my notes from adding chimp to an existing app, I'd recommend watching it there as I discuss the steps and reason for some design decisions in Chimp in depth. But if you want to be able to copy/paste some of the code, or if you want to be able to easier find this article with Google in the future, I'm leaving the notes here. :) The final diff is available here, but it's highly recommended watching the video or try the steps manually to get a "feel" of the chimp workflow. The diff tells only half of the story.

Note: We will base our work on this repository: and the selected branch (data-sources)

First, we will initialize chimp:

npx chimp init	

We need to manually configure jest.config.js

const { pathsToModuleNameMapper } = require("ts-jest/utils");  
const { compilerOptions } = require("./tsconfig");  
module.exports = {  
  preset: "ts-jest",  
  testEnvironment: "node",  
  moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths, {  
  prefix: "<rootDir>/"  

I'm removing these two dependencies from the package.json because they will be used as build-time, not run-time.

"@graphql-tools/graphql-file-loader": "^6.0.18",  
"@graphql-tools/load": "^6.0.18",

Add the tsconfig-paths to the start script

-r tsconfig-paths/register

Now we are ready to install dependencies:


Prepare context (./src/context.ts):

import { dataSources } from "~app/dataSources";  
export type GqlContext = { dataSources: ReturnType<typeof dataSources> };

Remove the example module.

Move Library to modules

Change dataSources.ts Library path


Library.books needs @computed 
Book.Library needs @link

Generate files with chimp:

yarn chimp

Optional: to make Webstorm happy mark top schema.graphql and generated/graphql/schema.ts as plaintext.

Move resolvers:

There will be an error in the return type of LibraryBooks - add @computed to Author.graphql book->Author

resolvers.ts - use chimpResolvers

import { resolvers as chimpResolvers } from "~generated/graphql/resolvers";

schema.ts - use ./schema.graphql

Check example query

query {
  libraries {
    books {
      author {
      library {

The existing test is passing.
The new ones are as well, although they are not implemented.
The one lines are probably not worth testing (types are doing their job)
BookLibrary has some logic so let's test that one.

test("BookLibrary", async () => {
  const context = td.object<GqlContext>();
    { id: "matchingId", branch: "matchingBranch" },
    { id: "notMatchingId", branch: "notMatchingBranch" },
  const parent: ParentType = {
    library: "matchingId",
    id: "some id ",
    title: "some title",

  const result = await testBookLibrary(parent, context);

  expect(result).toEqual({ id: "matchingId", branch: "matchingBranch" });

We also want to see it fail. - change === to !== in BookLibrary.ts resolver -

libraries.find((l) => !== book.library)

Once we see it fail we know that the test is doing its job.

Move Author to ./src/modules/

Change dataSources

yarn chimp

Looks like I'm missing one resolver, let's add that one.

extend type Author {
  books: [Book!]! @link

to src/modules/Library.graphql

query {
  libraries {
    books {
      author {
        books {
      library {

remove resolvers and schema

and finally in index.ts:

import { schema } from "~generated/graphql/schema";

Let me know if you have any questions or thoughts in the comments below.

Let us help you on your journey to Quality Faster

We at Xolvio specialize in helping our clients get more for less. We can get you to the holy grail of continuous deployment where every commit can go to production — and yes, even for large enterprises.

Feel free to schedule a call or send us a message below to see how we can help.

User icon
Envelope icon


Book a call
Loading Calendly widget...
  • Add types to your AWS lambda handler

    Lambdas handlers can be invoked with many different, but always complex, event arguments. Add to that the context, callback, matching return type and you basically start listing all the different ways that your function can fail in production.

  • How to expose a local service to the internet

    From time to time you might need to expose your locally running service to the external world - for example you might want to test a webhook that calls your service. To speed up the test/development feedback loop it would be great to be able to point that webhook to your local machine.

  • For loops in JavaScript (vs _.times)

    From time to time I still see a for loop in JavaScript codebases. Linters are frequently angry about them. Let's see how we can replace them.